> -----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.
>