"David Simmons" <David.Simmons at smallscript.com> wrote:
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> > admin at lists.squeakfoundation.org] On Behalf Of Marcel Weiher
> > Sent: Sunday, July 21, 2002 12:51 AM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Re: Animorphic ST (Strongtalk) released!
> > 
> > 
> > On Sunday, July 21, 2002, at 09:24  Uhr, David Simmons wrote:
> > 
> > > I think the general pattern of allowing <nil> to silently eat
> arbitrary
> > > messages sent to it is a dangerous (*bad*) practice.
> > 
> > Why do you think so?  I have been programming with message-eating
> <nil>
> > for around 15 years and I do not find it dangerous in practice.
> 
> Well, in and of itself, that is not a validation of it not being a
> "dangerous" practice.
> 
> There are programming patterns, which I've used for many years, which I
> would characterize as being "dangerous" for general purpose use by
> arbitrary programmers. 
> 
> In other words, it is one thing to adopt specific styles and specific
> techniques encapsulated within ones own code. It is an entirely
> different thing to standardize such techniques as best-practices,
> standard system behavior, or encouraged design techniques for all users
> of a language regardless of their background or the solution area they
> may apply those techniques/principles to.
> 
> The case of "black-hole" message receivers, <nil> is an especially
> troublesome one precisely because it is the default initialization value
> for all reference-type fields [slots]. 
> 
> It is quite easy to imagine how contractual errors and their resulting
> failures would go completely undetected because the "faulty" code is
> silent even at runtime. This is reminiscent of the really awful and
> unmaintainable unix code, that relied on zero-address behavior [and
> applications always loading at the same fixed addresses], that used to
> plague many of us who worked on unix software over the large span of
> years prior to the linux era [which obviously has much better coders
> ;-].
> 
> While your code over the last 15 years may not have had problems, I
> would ask you how you could really be sure?
> 
> What is missing (or eliminated by "black-hole" messaging to nil) is the
> explicit capturing of the programmer's intent and their stated
> "awareness" that they had a contract to fulfill. 
> 
> Which, in and of itself, would be acceptable for some problems if well
> encapsulated where such "black-hole" behavior was restricted to only
> apply to code for that problem.
> 
> But, since the only "classic Smalltalk" solution is to make "black-hole"
> messaging system/image wide, then it becomes quite troubling when any
> thought is given to teams of people integrating code which may come from
> unrelated parties and their distinct frameworks. 
> 
> I.e., modularized, componentized code intended for use in creating,
> maintaining, and extending complex systems -- which is one area where
> dynamic languages (and especially Smalltalk) have a flexibility that
> gives them an edge over other more mainstream and popular languages.
> 
> -- Dave S. [www.smallscript.org]
> 
> > 
> > Marcel
> > 
> > 
> > --
> > Marcel Weiher				Metaobject Software Technologies
> > marcel at metaobject.com		www.metaobject.com
> > Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.
> >