- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 11 October 2010 15:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> Now to me this looks like a hack and again it works because now Symbol are valuable objects. >>> Too many hacks will only make the system more hackish. >>> And especially the >>> Â Â Â Â iftrue: 'foo' ifFalse: 'zork' >>> >> >> This is not a hack, because if you refer to implementation: >> >> True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock >> Â Â Â ^trueAlternativeBlock value >> >> False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock >> Â Â Â ^falseAlternativeBlock value >> >> so, it answers either 'foo' value , or 'zork' value. >> And #value could be sent to any object in system: >> >> Object>>value >> Â Â Â ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. > > I know well that. and it sucks from a language semantics point of view. > I agree with the mail of lukas. > Okay, your obscurity barrier is higher than mine, and mine is higher than VW's, Nicolas and Levente's one :) > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

On Oct 11, 2010, at 1:28 PM, Lukas Renggli wrote: >> Object>>value >> ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. > > Magritte implemented Symbol>>#value: for a while before any Smalltalk > had this is their standard library. I must admit that I liked it in > the beginning, but in the long run I realized that ... > > 1. It is not easily understandable for newbies. > 2. It quickly leads to very unreadable, hard to understand and hard to > refactor code. > 3. It is very limiting in itself and quickly leads to other hacks > (like to replace sort blocks). > 4. #value and friends should be only understood by objects that can be > evaluated (certainly not by Object). A symbol (name) by itself cannot > be evaluated. + 200 > I eventually removed Symbol>>#value: for good. Re-occuring questions > in the mailing list disappeared. > > Therefor I strongly suggest to remove #value, #value:, and friends > from all objects that are not self-evaluable. BlockClosure and > MessageSend are self-evaluable. Only there it makes sense. > > If people are too lazy to create a block where something > self-evaluable is needed they should use a programming language > designed for cryptic code. Creating a block closure in Smalltalk is > concise and makes clear what happens easily. A symbol does not, you > need to exactly understand how this dispatches with various objects. This is exactly my point. Especially for system API like ifNotNil: When I read self bar: #zook I just know ok we are just passing a symbol as argument. I do not have to rely on the semantics of bar: so this is the only conclusion I can draw. Now I do not want to force people to have to understand the semantics of each single selector. In addition, it breaks nice rule such as use [ ] for any place where you do not know if the code will be executed. Simple nice and beautiful. [..]s delay execution and let the guy control it. Stef

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

>> >> >> Now to me this looks like a hack and again it works because now Symbol are valuable objects. >> Too many hacks will only make the system more hackish. >> And especially the >> iftrue: 'foo' ifFalse: 'zork' >> > > This is not a hack, because if you refer to implementation: > > True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^trueAlternativeBlock value > > False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^falseAlternativeBlock value > > so, it answers either 'foo' value , or 'zork' value. > And #value could be sent to any object in system: > > Object>>value > ^self > > What actually shown here is a use of duck typing, because any object, > which implemets #value, could be safely passed > as argument to #ifTrue:ifFalse: message. > It is well consistent with language design. I know well that. and it sucks from a language semantics point of view. I agree with the mail of lukas. Stef

Oct. 11, 2010

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

by StÃ©phane Ducasse

Hi we should improve from that side, but unfortunately we do not have enough man power to build tool that could support it. Stef On Oct 11, 2010, at 1:28 PM, Johannes Rasche wrote: > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! > > Thanks in advance > > > > > Johannes Rasche > Hagelberger Str. 56 > 10965 Berlin > > mail: johannesrasche(a)me.com > skype: johannesrasche > www: http://myNeat.de > fon: +49-30-7469 4425 (skypeIn) > fax: +49-30-315 66 821 > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

by Alain Plantec

Le 11/10/2010 13:27, Johannes Rasche a Ã©crit : > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to > change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in > the class comment? - cannot find a menu to edit translations - hidden > sowhere?) /Hi Johannes, arrrh, lack of man power... concerning the world menu, have a look at http://book.pharo-project.org/book/TipsAndTricks/WorldMenuRegistration then just ask more questions if you need, it will give us the opportunity to improve the documentation. Cheers Alain / > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release > to release - thanks for that !!!! > > Thanks in advance > > > > > /Johannes Rasche/ > /Hagelberger Str. 56/ > /10965 Berlin/ > / > / > /mail: johannesrasche(a)me.com <mailto:johannesrasche@me.com>/ > /skype: johannesrasche/ > /www: http://myNeat.de/ > /fon: +49-30-7469 4425 (skypeIn)/ > /fax: +49-30-315 66 821/ > > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 14:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > here a situation, with which we can deal in more safer manner: > > Suppose you have a weak registry, populated by different objects and > their executors. > > Now, when some of them died, a weak registry performs finalization. > > The potential danger is , that if there's an error triggered by some > executor(s), > then rest of executors will have no chance to run and will be > forgotten, causing memory leakage. > > What you think, should we handle this more graciously? > > (Consider a following meta-code) > > WeakRegistry>>finalizeValues > | executors | > Â executors := self gatherExecutorsToRun. > > Â executors do: [:ex | > Â Â [ ex finalize ] fork. > Â ]. > oh, and this gets even more complicated, if we keep supporting multiple finalizers per single object. :) executors do: [:ex | ex hasMultipleExecutors ifTrue: [ ex do: [ :eex | [ eex finalize ] fork ] ] ifFalse: [ [ ex finalize ] fork ]. > in this way, if any executor's #finalize causing error, it won't > interfere with other executors, and they will accomplish their task > normally. > Of course, i'm not saying that we should use #fork for this, because > it is costly. Similar could be done w/o forking. > I just wanted to show a simplest code with which we could achieve a > more gracious error handling. > > P.S. of course, in a first place it would be good to make sure that we > writing executors, which can't cause an error during finalization. > But bad things happen, and we should make sure that rest of system > won't be put on its knees because of some stupid bug in a single > #finalize. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 11 October 2010 14:28, Lukas Renggli <renggli(a)gmail.com> wrote: >> Object>>value >> Â Â Â Â ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. > > Magritte implemented Symbol>>#value: for a while before any Smalltalk > had this is their standard library. I must admit that I liked it in > the beginning, but in the long run I realized that ... > > 1. It is not easily understandable for newbies. > 2. It quickly leads to very unreadable, hard to understand and hard to > refactor code. > 3. It is very limiting in itself and quickly leads to other hacks > (like to replace sort blocks). > 4. #value and friends should be only understood by objects that can be > evaluated (certainly not by Object). A symbol (name) by itself cannot > be evaluated. > > I eventually removed Symbol>>#value: for good. Re-occuring questions > in the mailing list disappeared. > > Therefor I strongly suggest to remove #value, #value:, and friends > from all objects that are not self-evaluable. BlockClosure and > MessageSend are self-evaluable. Only there it makes sense. > > If people are too lazy to create a block where something > self-evaluable is needed they should use a programming language > designed for cryptic code. Creating a block closure in Smalltalk is > concise and makes clear what happens easily. A symbol does not, you > need to exactly understand how this dispatches with various objects. > In short: i'm not sharing your concerns about #value, but sharing about #value: because to understand what happens in following: result := foo bar ifTrue: x ifFalse: y. is much easier than in following: self perform: (object ifNil: #foo ifNotNil: #bar) :) > Lukas > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

[Pharo-project] Another finalization concern: error handling

by Igor Stasenko

Hello, here a situation, with which we can deal in more safer manner: Suppose you have a weak registry, populated by different objects and their executors. Now, when some of them died, a weak registry performs finalization. The potential danger is , that if there's an error triggered by some executor(s), then rest of executors will have no chance to run and will be forgotten, causing memory leakage. What you think, should we handle this more graciously? (Consider a following meta-code) WeakRegistry>>finalizeValues | executors | executors := self gatherExecutorsToRun. executors do: [:ex | [ ex finalize ] fork. ]. in this way, if any executor's #finalize causing error, it won't interfere with other executors, and they will accomplish their task normally. Of course, i'm not saying that we should use #fork for this, because it is costly. Similar could be done w/o forking. I just wanted to show a simplest code with which we could achieve a more gracious error handling. P.S. of course, in a first place it would be good to make sure that we writing executors, which can't cause an error during finalization. But bad things happen, and we should make sure that rest of system won't be put on its knees because of some stupid bug in a single #finalize. -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] another little OB "bug"

by Lukas Renggli

>> Â Name: OB-Morphic-lr.149 >> Â Author: lr >> Â Time: 11 October 2010, 10:17:53 am >> Â UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e >> Â Ancestors: OB-Morphic-lr.148 >> >> Â - more efficient fix for list updating >> >> I try to remember the current scroll position before updating any OB >> list, so I guess this works around the problem (indeed the UI feels >> better after the change). > > Indeed, it works perfect :) Thanks lukas Well, I noticed a first problem: Going to a different category/class/protocol leaves the selector list scrolled to the bottom (if there is no default selection). Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Lukas Renggli

> Object>>value > Â Â Â Â ^self > > What actually shown here is a use of duck typing, because any object, > which implemets #value, could be safely passed > as argument to #ifTrue:ifFalse: message. > It is well consistent with language design. Magritte implemented Symbol>>#value: for a while before any Smalltalk had this is their standard library. I must admit that I liked it in the beginning, but in the long run I realized that ... 1. It is not easily understandable for newbies. 2. It quickly leads to very unreadable, hard to understand and hard to refactor code. 3. It is very limiting in itself and quickly leads to other hacks (like to replace sort blocks). 4. #value and friends should be only understood by objects that can be evaluated (certainly not by Object). A symbol (name) by itself cannot be evaluated. I eventually removed Symbol>>#value: for good. Re-occuring questions in the mailing list disappeared. Therefor I strongly suggest to remove #value, #value:, and friends from all objects that are not self-evaluable. BlockClosure and MessageSend are self-evaluable. Only there it makes sense. If people are too lazy to create a block where something self-evaluable is needed they should use a programming language designed for cryptic code. Creating a block closure in Smalltalk is concise and makes clear what happens easily. A symbol does not, you need to exactly understand how this dispatches with various objects. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010