On Sunday, July 21, 2002, at 02:40  Uhr, David Simmons wrote:

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

I didn't say it was a validation.  It is evidence, a *counterexample* to 
your claim that it is a dangerous practice.  Since you are making the 
claim, it is up to you to validate it.

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

Hmm...like using Smalltalk?

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

You are quite wrong:  this is the standard behavior in Objective-C, so 
it isn't just my personal style of coding.

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

Actually, I find the combination to be rather useful.  If I don't put 
anything there, nothing is there, and this nothing does nothing and 
returns nothing when asked to to something.  Which I find to be 
perfectly acceptable behavior for nothing.

> It is quite easy to imagine

Imagination is one thing...experience another.  Somehow, this reminds me 
of all the awful things that people (strongly) advocating mandatory 
static+manifest typing keep telling Smalltalkers will happen, which 
Smalltalkers just don't seem to see happening.  Show me some evidence 
that this actually *does* happen in real life, and maybe I will be 
convinced.

> how contractual errors and their resulting
> failures would go completely undetected because the "faulty" code is
> silent even at runtime.

You mean like objects of the wrong type that get transported to other 
parts of the system to lie dormant until they blow up years later?  Yes, 
these things can happen, but the question is wether their frequency 
outweighs the frequency of errors that could have been ignored but 
weren't, and the amount of extra code you have to write to constantly 
check for nil, code that can and will introduce bugs of its own.

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

I don't think the analogy holds, and I don't find reminiscences very 
convincing "validation", much less convincing in fact than a decade plus 
of actually working with the pattern.

> While your code over the last 15 years may not have had problems, I
> would ask you how you could really be sure?

The only thing I am sure about my code is that it contains bugs.

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

Like Java's mandatory catching of declared exceptions?  Sorry, I find 
that this actually obscures intent more than it clarifies it, because 
the code you intend to write gets obscured by code you have to write 
because the language is being anal.

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

I don't see the problem.  If you want or need to check for nil, you can 
still do that.  You just don't have to do it at *every step of the way* 
for longer expressions.

> 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 don't see any validation for your claim that this becomes troubling.  
None whatsoever.  I just have evidence to the contrary.

Marcel

--
Marcel Weiher				Metaobject Software Technologies
marcel at metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.