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 at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Nevin Pratt
> Sent: Sunday, July 21, 2002 4:21 PM
> To: squeak-dev at 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
> 
> 
> 
> 
>