-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Marcel Weiher Sent: Sunday, July 21, 2002 12:51 AM To: squeak-dev@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@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.