[Pharo-project] Compiler pedantic about ifNotNil: argument
leves at elte.hu
Mon Oct 11 08:53:24 EDT 2010
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.
> 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
More information about the Pharo-dev