[Pharo-project] Compiler pedantic about ifNotNil: argument

Lukas Renggli renggli at gmail.com
Mon Oct 11 07:28:08 EDT 2010

> 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 Renggli

More information about the Pharo-dev mailing list