[Pharo-project] Compiler pedantic about ifNotNil: argument
siguctua at gmail.com
Mon Oct 11 07:45:48 EDT 2010
On 11 October 2010 14:28, Lukas Renggli <renggli at gmail.com> 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.
> 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 Renggli
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev