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

[Richard O'Keefe]

On 26 Sep 2008, at 3:57 pm, Andres Valloud wrote:
> 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
>

Since I consider it rather bad style to use the value of
a one-armed-if of any kind (being a Bear of Very Little Brain,
I have enough trouble remembering important stuff), for me this
difference effectively does not exist.  Like Sherlock Holmes, I
cherish my ignorance in certain areas, so I mean to forget your
clarification as soon as I possibly can.

> "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.: <snip>"

Stephen Jay Gould often wrote about the distinction between
historic origin and present value.  I mainly use #ifNil: in the
lazy initialisation pattern.
>
>
> With that in mind, the snippet above becomes
>
> name := expression.
> name notNil ifTrue: [...]

Let's take the lazy initialisation pattern.

	foobar
	    FooBar ifNil: [FooBar := ....].
	    ^FooBar

(written that way, not as ^FooBar ifNil: [...], because
I don't return the values of one-armed-ifs.)  Now, is this

	FooBar isNil ifTrue: [...]
	FooBar isNil ifFalse: [...]
	FooBar notNil ifTrue: [...]
	FooBar notNil ifFalse: [...]

I've found that I make fewer mistakes going straight to #ifNil:.
So that's what I do.  I also find it easier to read.
As I think has been discussed before, this argument would also
apply to #ifEmpty:ifNotEmpty:, and to #ifAtEnd:ifNotAtEnd:,
were that to exist.  And I certainly don't want to be thought of
as recommending those.
>

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

"What are we after" has to be THE best question that's been asked
so far.

Let me offer an anecdote:  the very first contributed item I looked
at in VW7.5NC had
	ifFalse:	2
	ifTrue:		1
	ifTrue:ifFalse:	2
	ifNotNil:	2
	ifNil:		2
In another contribution, that had been written for portability,
at least 1/7th of the ifFalse: or ifTrue: cases could have been
ifNil: or ifNotNil: and would, in my view, have been clearer.
(This figure, that about 1/7 of the ifs would naturally be ifNil
or ifNotNil, is typical of my own code as well.  I don't know how
general this is.)

The purpose of a standard is to increase the usefulness of the
language by making it easier for people to write more,and more
kinds of, software in a portable way if they want to.

The question is where the payoff is:  would we be better off
arguing about a standard binding for ODBC or about #ifNil:?
I would very much like #ifNil: in the standard, but we *can*
manage without it, as Andres Valloud correctly remarks.  It is
much much harder to make do without a standard ODBC binding.

like