[snip]
But it isn't so. nil *is* an instance of Object, after all, and does respond to a number of Object-related messages, in particular: "hash," "isLiteral," "fullPrintString," (even clone, although it just returns self).
So, nil as a truly undefined object has no pure, sacrosanct, theoretical definition, akin to the "bottom" of a denotational semantics. Or does it? Have we compromised its meaning as an undefined object over the years in the interest of producing a "practical" system, or just lapsed from time to time, and perpetuated the lapses for conveniences precisely of the kinds we saw when beloved "size" was removed from the list of "special" message to which the sole UndefinedObject would give meaning?
And, as to those objections, does the lack of purity of nil suggest that an Undefined object may not be what we need for our most "special" object? In particular, is it possible that instead of an UndefinedObject, what is really needed is an EverywhereDefinedObject, a construct, call it "top" or maybe "superSelf", which responds to each and every message sent to it with, say, itself?
Yes, I've often had similar thoughts. UndefinedObject seems self-contradictory. nil is the singleton of UndefinedObject, a descendant of Object, and is therefore a fully defined object in the hard sense (an object as chunk of bytes in memory), but represents the *concept of an undefined object. This is an unfortunate clash of hard and soft object realities, and is an example of the delicate self-deception that is everywhere in natural language.
That said, I don't see an especially pleasing alternative. Perhaps class Nothing would be more appropriate, but it really has essentially the same I'm-lying-to-myself-but-I-can-do-my-work-this-way quality. Then there is Any whose singleton nil could do anything in response to any message, but this would create confusion to justify a more flexible, "whatever I need for convenient programming" method response pattern. How about Nil and its singleton nil? This is just the computerese version of the more general Nothing, which I actually preferred.
Somehow, I suspect that none of the above actually helps. :)
Given my relative newbieness in Smalltalk, and the high caliber of computer scientists practicing in this area, I'll presume this has been considered and analyzed before before sticking my neck out much further, but I'd be curious for pointers on the subject.
In particular, is there a simple, definitive notion of what nil *is* (or is not), that would answer the question definitively whether or not it should respond to size? (It would seem, if there were, there are examples of other "lapses" that can be found simply by examining UndefinedObject.) Has the idea of "top" been previously considered?
I think the new, stricter size-semantic revolves around the idea that: you can only determine the size of an object that has size; size is a countable quantity; and counting begins with one. Zero is not a count, but our culture is very comfortable with the idea because it pervades our math, physics, and finance, and because more of us are programming computers these days. (Zero, as an invention, was an unecessary mistake. Don't bug me about that; it would lead to far... :))
I like the stricter semantic, and I'm willing to code the extra checks for nil.
Cheers.