Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
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' 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
On 11 October 2010 13:53, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
On 11 October 2010 14:28, Lukas Renggli <renggli@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
2010/10/11 Levente Uzonyi <leves@elte.hu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
"Lukas" == Lukas Renggli <renggli@gmail.com> 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 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
participants (6)
-
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
merlyn＠stonehenge.com -
Nicolas Cellier -
Stéphane Ducasse