[ANSI-Smalltalk] Re: A list of interesting methods, ifNotNil:

[Andres Valloud]

Richard,

> Parentheses aren't really relevant here.
> It's having a name for the result.
>
> Me, I've always considered it better style to do
>
>        name := expression.
>        name ifNotNil: [...].

I try not to use ifNil:/ifNotNil: as a conditional branch control
message because they do not behave the same as ifTrue:ifFalse:.  For
example,

false ifTrue: [5] => nil
3 ifNil: [5] => 3

Once upon a time there was a discussion about this in the Squeak
mailing list... something like 1998 or so... and Dan Ingalls (and a
few others the names of whom now I do not remember) came back with an
argument along the lines of

"Yes, they do not behave the same because they're meant for different
things.  The messages ifNil:/ifNotNil: were meant as messages that
provide a default value, e.g.:

someObjects

 ^someObjects ifNil: [Array new]


Therefore, they should be read as 'but if nil, then...'."


With that in mind, the snippet above becomes

name := expression.
name notNil ifTrue: [...]


But then you do not need the argument name nor parentheses... in fact,
this is possible since one has the identifier 'name'.  I'd go as far
as venturing that when one writes code like this,

^(someExpression etc etc etc) ifNotNilDo: [:x | x something]


one is being intention obscuring precisely because several statements
have been rolled into one via aggressive syntactic inlining.  I'd
rather not do that, and so I do not immediately see a lot of value in
ifNilDo:/ifNotNilDo:.

Now, that discussion aside, what are we going to do from the point of
view of the standard?  What are we after here?

Andres.