Hi Nevin,
Thanks for the info. I think I'll just have to try it out :-) I still find it hard to believe that code which was written with exception throwing behavior in mind would fail if you introduce message eating behavior but I guess only experience can really tell the ups and downs.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Nevin Pratt Sent: Sunday, July 21, 2002 4:21 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Animorphic ST (Strongtalk) released!
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