[Pharo-project] Compiler pedantic about ifNotNil: argument

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Oct 11 08:21:49 EDT 2010


On Oct 11, 2010, at 1:28 PM, 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.
> 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.


+ 200

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

This is exactly my point. Especially for system API like ifNotNil: 

When I read self bar: #zook

I just know ok we are just passing a symbol as argument. 
I do not have to rely on the semantics of bar: so this is the only conclusion I can draw.
Now I do not want to force people to have to understand the semantics of each single selector.

In addition, it breaks nice rule such as 

	use [ ] for any place where you do not know if the code will be executed. 
	Simple nice and beautiful. [..]s delay execution and let the guy control it. 


Stef














More information about the Pharo-dev mailing list