[Pharo-project] Compiler pedantic about ifNotNil: argument
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.
>> 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
False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
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.
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev