(foo ifNil: [foo := false]) ifTrue: [ … ] ifFalse: [ … ].

This means that for

foo ifNil: [foo := false] ifTrue: [ … ] ifFalse: [ … ]

to work the same way, the following would need to be implemented something like this.

!UndefinedObject methods!
ifNil: nilBlock ifTrue: trueBlock ifFalse: falseBlock
^nilBlock value ifTrue: trueBlock ifFalse: falseBlock

Of course if this control structure isn’t used for “lazy initialization” the following could be the implementation on UndefinedObject which simply evaluates the nil block and returns; naturally true and false would be implemented in a similar manner. This is the normal expected way of doing this sort of protocol in Smalltalk.

!UndefinedObject methods!
ifNil: nilBlock ifTrue: trueBlock ifFalse: falseBlock
^nilBlock value

Refining the more flexible version to handle both scenarios better:

!UndefinedObject methods!
ifNil: nilBlock ifTrue: trueBlock ifFalse: falseBlock
| result |
result := nilBlock value.
result ifNil: [^self] ifNotNil: [
result == true ifTrue: [^ trueBlock value ].
result == false ifTrue: [^ falseBlock value ]
].
^result

Not the nicest implementation but it gets the job done for the “normal case” and the “lazy initialization” case. Now if after the lazy initialization it’s true or false one of those two true/false blocks will get executed, otherwise the value is simply returned. Of course we can, and likely would want for some cases, the “ifNotNil:” keyword added to the protocol pattern; like so:

!UndefinedObject methods!
ifNil: nilBlock ifNotNil: notNilBlock ifTrue: trueBlock ifFalse: falseBlock
| result |
result := nilBlock value.
^ result ifNil: [self] ifTrue: [ trueBlock ] ifFalse: [ falseBlock ]

!Object methods!
ifNil: nilBlock ifNotNil: notNilBlock ifTrue: trueBlock ifFalse: falseBlock
^ notNilBlock isOneArgumentBlock
ifTrue: [ notNilBlock value: self ]
ifFalse: [ notNilBlock value ]

!True methods!
ifNil: nilBlock ifNotNil: notNilBlock ifTrue: trueBlock ifFalse: falseBlock
^ trueBlock value

!False methods!
ifNil: nilBlock ifNotNil: notNilBlock ifTrue: trueBlock ifFalse: falseBlock
^ falseBlock value

Ok, not perfect but it covers the cases mentioned above. With a set of sunit tests to ensure that it works as expected in all the cases we can begin to use it throughout code for “lazy initialization” scenarios plus others. Naturally It could also be re-implemented with a double dispatch.

However, something is nagging me about this protocol… that is that unlike other similar protocols in Smalltalk which simply “branch” on the receiver (ifTrue:, ifFalse:, ifNil:, ifNotNil:) this one recomputes when the receiver is nil and then branches based on the receiver of the re-computation. This changes the basic assumptions of the normal protocols which programmers might come to expect as normal. Sometimes it’s best to not challenge these basic assumptions too much as it could be a source of bugs due to misinterpretations; after all our goal is to make coding safer and simpler, not more complex or obscure. (If you really want more obscure and complex coding use a language such as Perl which implements new features in language syntax rather than in an extensible library).

So while this is an interesting protocol I’d likely not actually use it in practice. So it’s not been a very good example after all; however, it’s been interesting in that not all experiments or attempts to create new control structures for Smalltalk work out in practice. Maybe later I’ll work out another alternative, or maybe not. The point is that Smalltalk allows for these experiments to be carried out without changing the language syntax! It means that Smalltalk can adapt to your needs and the needs of your application; and isn’t that what software is for?

APPRECIATING the BEAUTY OF “OBJECT PASS THROUGH” in PROTOCOLS
Taking another look at this:

(foo ifNil: [foo := false]) ifTrue: [ … ] ifFalse: [ … ]

we can see that there are a number of possible cases: foo is nil, foo is true, foo is false, foo is some other object. If foo is some other object (other than a boolean) it will be passed through “ifNil:” - in this case we’ll get an error since most objects don’t understand ifTrue:ifFalse. However, we’re expecting foo to be true or false for this variable; and the lazy initializer sets it up for us with “(foo ifNil: [foo := false])”. What’s interesting about “ifNil:” is that if foo isn’t nil the “ifNil:” simply returns the receiver by passing it through the “ifNil:” message! This allows the subsequent messages to be sent to the receiver, which in this case is foo, whether or not it’s been initialized lazily here. The same works for “ifNotNil:” in the case of “nil”; for example:

(someObject ifNotNil: [ ... ]) someMessage.

If someObject is nil the message “someMessage” will be sent to nil, and if someObject is a non nil object of some kind the block will execute returning it’s object for “someMessage” to be sent to.

When constructing your own control structure protocols it’s important to choose which objects are returned from the protocol for each case. This allows for compact beauty. Beauty and simplicity enable power of expression

It’s the one of the first adjustments which I always add to any Smalltalk when I start using it. Recently I added it to Susie Smalltalk.

UNIFORMITY+SYMMETRY IN PROTOCOLS
It’s actually useful in a number of limited cases to allow a parameter for “ifNil:” for uniformity purposes. For example, when the block is being passed around to various statements this can save a lot of other coding. The value passed into the ifNil: block is, of course, nil.

self foo ifNil: aBlock.
self bar ifNotNil: aBlock.

It makes ifNil: and ifNotNil: uniform and symmetric in terms of their calling usage with blocks. It’s makes them interchangeable. Another example where the message selector is either “ifNil:” or “ifNotNil:” is in “plug and play” of components.

self perform: aMessageSelector with: aBlock.

While ifNil: and ifNotNil: are asymmetric in semantics (as pointed out above in the article) they can be made uniform and symmetric in their message sending usage.

STANDARDIZATION: Smalltalk 2010
I think we should propose ifNil:, ifNotNil:, ifNil:ifNotNil:, and ifNotNil:ifNil: with or without a one argument block become part of the Smalltalk standard.

Years ago I added these to VisualWorks while working on a very large project at a Wall Street company. Six months later I was instructed to remove them and convert all the hundreds of senders to the “isNil ifTrue:ifFalse:” semantic for a few reasons: 1) it was an addition to a base class and they didn’t want to do that; 2) it wasn’t “standard Smalltalk” and they didn’t like to read it; and, 3) it was slower than the alternative. All the arguments (which you have expressed above) for this ifNil: enhancement were tossed aside. I’m glad the times have changed.

BEYOND THE FUTURE
Now to push the future further. How about this useful tidbit (and it’s other variations) that’s helpful in dealing with those pesky situations when you really don’t know what’s coming back from “foo”.

self foo ifNil: [ ... ] ifNotNil: [:aReceiver | ... ] ifTrue: [ ... ] ifFalse: [ ... ].

For example “ifNil:ifTrue:ifFalse:” is useful for lazy initialization.

foo ifNil: [foo := false] ifTrue: [ ... ] ifFalse: [ ... ].

The above replaces the following. It might not seem much different but it is less verbose.

(foo ifNil: [foo := false]) ifTrue: [ ... ] ifFalse: [ ... ].

One of the powerful advantages of Smalltalk syntax is that control structures are implemented in the object library and anyone can add new and useful control structures. Another powerful advantage of “pre-canned” control structures is that once they are tested (using something like sunit) they can increase the reliability of the code which uses them; since it’s less likely for mistakes to be made inlining and reproducing the logic of the control structure each time.