[Pharo-project] Compiler pedantic about ifNotNil: argument
nicolas.cellier.aka.nice at gmail.com
Mon Oct 11 13:23:15 EDT 2010
2010/10/11 Levente Uzonyi <leves at elte.hu>:
> On Mon, 11 Oct 2010, Lukas Renggli wrote:
>>> 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
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.
>> 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 Renggli
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev