Animorphic ST (Strongtalk) released!
Nevin Pratt
nevin at smalltalkpro.com
Sun Jul 21 14:20:50 UTC 2002
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
More information about the Squeak-dev
mailing list
|