[Pharo-project] Compiler pedantic about ifNotNil: argument

Igor Stasenko siguctua at gmail.com
Mon Oct 11 07:02:52 EDT 2010

On 11 October 2010 13:53, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>> personnally I do not like this form
>>> What does it do?
>>>>  process ifNotNil: #terminate.
>>> for me it means passes the symbol #terminate as argument to the method ifNotNil:
>>> If it has a more magical behavior then I do not know it.
>>> Stef
>> It's exactly the same as using collection do: #something.
>> FWIW, in 1.2 we already included the compiler changes Levente suggested to me to remove this restriction, so
>> nil ifNotNil: #squared -> nil
>> 4 ifNotNil: #squared -> 16.
> This is still not really readable compared to
>        4 ifNotNil: [:rec | rec squared]
> For select: #even why not
> Now to me this looks like a hack and again it works because now Symbol are valuable objects.
> Too many hacks will only make the system more hackish.
> And especially the
>        iftrue: 'foo' ifFalse: 'zork'

This is not a hack, because if you refer to implementation:

True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
	^trueAlternativeBlock value

False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
	^falseAlternativeBlock value

so, it answers either 'foo' value , or 'zork' value.
And #value could be sent to any object in system:


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.

> In Smalltalk this is simple you ut bracket when you do not know if a part should/will be executed.
> Now with such change this is not the case anymore.
> I think that we are focusing on the wrong point. Changing the language that way does not
> bring anything really useful.
> And I would veto such usage in the core for consistency reason.
> Stef
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Best regards,
Igor Stasenko AKA sig.

More information about the Pharo-dev mailing list