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