Compiler pedantic about ifNotNil: argument
Locked
12
12
Re: Compiler pedantic about ifNotNil: argument
 
|
On 11 October 2010 13:53, Stéphane Ducasse <[hidden email]> wrote:
>> personnally I do not like this form >>> What does it do? >>> >>>> process ifNotNil: #terminate. >>> >>> >>> for me it means passes the symbol #terminate as argument to the method ifNotNil: >>> If it has a more magical behavior then I do not know it. >>> >>> Stef >> >> It's exactly the same as using collection do: #something. >> >> FWIW, in 1.2 we already included the compiler changes Levente suggested to me to remove this restriction, so >> >> nil ifNotNil: #squared -> nil >> 4 ifNotNil: #squared -> 16. > > This is still not really readable compared to > 4 ifNotNil: [:rec | rec squared] > > For select: #even why not > > 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. > In Smalltalk this is simple you ut bracket when you do not know if a part should/will be executed. > Now with such change this is not the case anymore. > I think that we are focusing on the wrong point. Changing the language that way does not > bring anything really useful. > > And I would veto such usage in the core for consistency reason. > > Stef > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
On 11 October 2010 14:28, Lukas Renggli <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Igor Stasenko
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Stéphane Ducasse
On 11 October 2010 15:18, Stéphane Ducasse <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Lukas Renggli
On Mon, 11 Oct 2010, 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). That "hack" is really cool IMO. The code is easily understood by anyone: #(4 1 3 5 2) sort: #<=. > 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. That's strange, because Symbol >> #value: was added to Squeak in 2006 during the developement of 3.9. Levente > > 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 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
>> I eventually removed Symbol>>#value: for good. Re-occuring questions
>> in the mailing list disappeared. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. Why? Filename: Magritte-All-lr.185.mcz Author: Lukas Renggli Timestamp: 19 January 2007 2:25:14 pm UUID: e26ba5b5-15b0-4128-9839-1536359b89f0 Ancestors: Magritte-All-lr.184.mcz - removed #value: and #value:value: from Symbol (this is now in 3.9 and not really cool) - changed all (or most) references to these methods -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
On Mon, 11 Oct 2010, Lukas Renggli wrote:
>>> I eventually removed Symbol>>#value: for good. Re-occuring questions >>> in the mailing list disappeared. >> >> That's strange, because Symbol >> #value: was added to Squeak in 2006 during >> the developement of 3.9. > > Why? > > Filename: Magritte-All-lr.185.mcz > Author: Lukas Renggli > Timestamp: 19 January 2007 2:25:14 pm > UUID: e26ba5b5-15b0-4128-9839-1536359b89f0 > Ancestors: Magritte-All-lr.184.mcz > > - removed #value: and #value:value: from Symbol (this is now in 3.9 > and not really cool) > - changed all (or most) references to these methods I'm not questioning that you added it to Magritte before 3.9 picked it up. I just didn't understand how could the re-occuring questions disappear, because Symbol >> #value: was still in the system. But I guess people didn't understand the code which used this feature. Levente > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
>> Filename: Magritte-All-lr.185.mcz
>> Author: Lukas Renggli >> Timestamp: 19 January 2007 2:25:14 pm >> UUID: e26ba5b5-15b0-4128-9839-1536359b89f0 >> Ancestors: Magritte-All-lr.184.mcz >> >> - removed #value: and #value:value: from Symbol (this is now in 3.9 >> and not really cool) >> - changed all (or most) references to these methods > > I'm not questioning that you added it to Magritte before 3.9 picked it up. I > just didn't understand how could the re-occuring questions disappear, > because Symbol >> #value: was still in the system. But I guess people > didn't understand the code which used this feature. I was referring to the magritte mailing-list, check the archive. Lukas > > > Levente > >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Lukas Renggli
>> That "hack" is really cool IMO. The code is easily understood by anyone:
> > #(4 1 3 5 2) sort: #<=. yes in Moose people are using that a lot for scripting. Now the problem is that as soon as you need more you have to get a block. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
On Mon, 11 Oct 2010, Stéphane Ducasse wrote:
>>> That "hack" is really cool IMO. The code is easily understood by anyone: >> >> #(4 1 3 5 2) sort: #<=. > > yes in Moose people are using that a lot for scripting. Now the problem is that as soon > as you need more you have to get a block. Why is that a problem? You can use the symbol for simple cases and write blocks for the complicated ones. Levente > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Stéphane Ducasse
On Oct 11, 2010, at 3:55 PM, Levente Uzonyi wrote: > On Mon, 11 Oct 2010, Stéphane Ducasse wrote: > >>>> That "hack" is really cool IMO. The code is easily understood by anyone: >>> >>> #(4 1 3 5 2) sort: #<=. >> >> yes in Moose people are using that a lot for scripting. Now the problem is that as soon >> as you need more you have to get a block. > > Why is that a problem? You can use the symbol for simple cases and write blocks for the complicated ones. Indeed this is why we added Symbol>>value, even if I was against because been burned by Object>>value in some VW projects :) Now I do not see the point for ifNotNil: and for ifTrue:ifFalse: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
On Mon, 11 Oct 2010, Stéphane Ducasse wrote:
> > On Oct 11, 2010, at 3:55 PM, Levente Uzonyi wrote: > >> On Mon, 11 Oct 2010, Stéphane Ducasse wrote: >> >>>>> That "hack" is really cool IMO. The code is easily understood by anyone: >>>> >>>> #(4 1 3 5 2) sort: #<=. >>> >>> yes in Moose people are using that a lot for scripting. Now the problem is that as soon >>> as you need more you have to get a block. >> >> Why is that a problem? You can use the symbol for simple cases and write blocks for the complicated ones. > > Indeed this is why we added Symbol>>value, even if I was against because been burned by Object>>value in some VW projects > > :) > > Now I do not see the point for ifNotNil: and for ifTrue:ifFalse: a logical change. I probably won't use that feature though. But I like the monadic block <-> keyword selector substitution. Maybe the best is to add a setting/preference to the compiler. Levente > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Stéphane Ducasse
I think that for typing in a transcript experessions when you want to experiment with something
selectors are fun but not in method body. But I know that this is not a really good argument. Just feeling. May be we get trapped in our way of thinking. >>>>>> > I personally don't like the ifTrue:ifFalse: related changes, though it's a logical change. I probably won't use that feature though. But I like the monadic block <-> keyword selector substitution. Maybe the best is to add a setting/preference to the compiler. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Lukas Renggli
>>>>> "Lukas" == Lukas Renggli <[hidden email]> writes:
Lukas> 1. It is not easily understandable for newbies. Lukas> 2. It quickly leads to very unreadable, hard to understand and hard to Lukas> refactor code. Lukas> 3. It is very limiting in itself and quickly leads to other hacks Lukas> (like to replace sort blocks). Lukas> 4. #value and friends should be only understood by objects that can be Lukas> evaluated (certainly not by Object). A symbol (name) by itself cannot Lukas> be evaluated. +1 Lukas> If people are too lazy to create a block where something Lukas> self-evaluable is needed they should use a programming language Lukas> designed for cryptic code. Creating a block closure in Smalltalk is Lukas> concise and makes clear what happens easily. A symbol does not, you Lukas> need to exactly understand how this dispatches with various Lukas> objects. Agreed. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Stéphane Ducasse
I think this discussion has diverged a lot from the original question, which is to do with the compiler being too pedantic.
#ifNotNil: and friends are the selectors of methods which just happen to give the compiler an opportunity for a nice optimization, in the case when the argument that follows is a literal block. In all other cases they can be treated as message sends. If the compiler starts to impose limitations on the language just because some magic selectors can be treated specially, then IMO it is not behaving as it should. Smalltalk is beautiful because it is so simple: everything is an object, and all processing is done by sending messages to objects. Of course, in the interests of speed, we can write a compiler that actually does something different under the covers, like causing a branch in the byte codes instead of sending a message, and of course the cases when that can be done need to be clearly defined. But that does not mean that these magic selectors should be allowed to pose limitations on how they can be used, because then we no longer have Smalltalk, we have Smalltalk-- instead. Now, the above discussion is orthogonal to the questions of what is good style, what is readable, maintainable, understandable to newbies, etc, etc. Those questions are IMO just as important, but they should have nothing do do with what the compiler is supposed to do. If the compiler is being too pedantic, then it should be fixed. Then we can start discussing good style without mixing apples and oranges together. -- Cheers, Peter On Mon, Oct 11, 2010 at 5:03 PM, Stéphane Ducasse <[hidden email]> wrote: I think that for typing in a transcript experessions when you want to experiment with something _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
2010/10/11 Peter Hugosson-Miller <[hidden email]>:
> I think this discussion has diverged a lot from the original question, which > is to do with the compiler being too pedantic. > > #ifNotNil: and friends are the selectors of methods which just happen to > give the compiler an opportunity for a nice optimization, in the case when > the argument that follows is a literal block. In all other cases they can be > treated as message sends. If the compiler starts to impose limitations on > the language just because some magic selectors can be treated specially, > then IMO it is not behaving as it should. > > Smalltalk is beautiful because it is so simple: everything is an object, and > all processing is done by sending messages to objects. Of course, in the > interests of speed, we can write a compiler that actually does something > different under the covers, like causing a branch in the byte codes instead > of sending a message, and of course the cases when that can be done need to > be clearly defined. But that does not mean that these magic selectors should > be allowed to pose limitations on how they can be used, because then we no > longer have Smalltalk, we have Smalltalk-- instead. > +100. You allowed to cheat, just not get caught! > Now, the above discussion is orthogonal to the questions of what is good > style, what is readable, maintainable, understandable to newbies, etc, etc. > Those questions are IMO just as important, but they should have nothing do > do with what the compiler is supposed to do. If the compiler is being too > pedantic, then it should be fixed. Then we can start discussing good style > without mixing apples and oranges together. > Amen :) > -- > Cheers, > Peter > > On Mon, Oct 11, 2010 at 5:03 PM, Stéphane Ducasse > <[hidden email]> wrote: >> >> I think that for typing in a transcript experessions when you want to >> experiment with something >> selectors are fun but not in method body. But I know that this is not a >> really good argument. Just feeling. >> May be we get trapped in our way of thinking. >> >> >> >>>>>> >> > I personally don't like the ifTrue:ifFalse: related changes, though it's >> > a logical change. I probably won't use that feature though. But I like the >> > monadic block <-> keyword selector substitution. Maybe the best is to add a >> > setting/preference to the compiler. >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Levente Uzonyi-2
2010/10/11 Levente Uzonyi <[hidden email]>:
> On Mon, 11 Oct 2010, 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. > > That's true. > Well, it depends. Very newbies can understand it because they trust the words. My son did. More advanced newbies can wonder how the hell this could work eventually, because they can differentiate a regular message and a literal #symbol. It's true that writing code is another matter. Why and when to use a block a message or a Symbol ? Maybe a newbie could be tempted to write: x > 1 and: #even. which currently does not work. >> 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). > > That "hack" is really cool IMO. The code is easily understood by anyone: > > #(4 1 3 5 2) sort: #<=. > >> 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. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. > > > Levente > >> >> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |