Andreas Raab wrote:

>>
>>isNil ifTrue: (which would work, as it's a message send)
>>== nil ifTrue: (which wouldn't work)
>>ifNil: (which also wouldn't)
>>
>>etc. in Squeak.
>>
> 
> Nah... I meant the "real thing", e.g., make UndefinedObject be "message
> eating" not some arbitrarily new object. All of the above should work
> perfectly well if you implement them.


The main reason I recommended against this in my article is because I 
found from experience that making UndefinedObject be "message eating" 
breaks large amounts of existing code.  Implement it yourself, and you 
will discover the same thing very rapidly.  For example, streams in 
VisualWorks deliberately throw and catch exceptions as part of the 
normal processing.  If you eliminate the exception throwing, the code 
breaks.

So, rather than modifying UndefinedObject, I attempted to mix the 
paradigms.  I immediately encountered difficulty trying to mix existing 
nil behavior with a message eating Null class within the same software 
layer.  I.e., things would break when I would try mixing it within the 
Presentation Layer, because existing widgets, etc., in the Presentation 
Layer again expect alternate nil behavior.  Of course, one reason for 
this is simply a rehash of the same issue above.

I also encountered difficulties trying to mix the paradigms in 
VisualAge, where #isNil: and #notNil: are optimized away and are not 
true message sends.  Another Smalltalk that doesn't optimize away 
#isNil: and #notNil: might yield different results, though.  But even 
then, there is still the problem of '== nil' that many programmers like 
to write (but not me) if you are trying to mix the paradigms.

As mentioned in the article, the entire experience was originally done 
as an experiment, and was motivated from my Objective-C experience.  I 
was initially apprehensive about it, but have since concluded that most 
of that apprehension was just excessive paranoia.

I have long concluded that the paradigm is very useful when applied to 
Smalltalk, and is trouble-free, *if* the entire software layer that it 
is being used in has been written with that paradigm in mind.  And, for 
practical reasons, I feel that the only layer that you have any chance 
of achieving that is the domain layer (if at all), since that is the 
layer you most control.  But regardless of the layer, it requires the 
buy-in of the other team members writing code for that layer, or it 
won't work.

So, within that narrow usage, I find it to be a very useful paradigm. 
But I agree it is not suitable for the general case.

Interestingly enough, Dolphin Smalltalk has had a 'DeafObject' class in 
it's image since about 1996, which predates my article.  The 
'DeafObject' does essentially what my 'Null' does.

Nevin