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@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.