>Adding ProtoObject to the hierarchy makes things more consistent,
>because being a subclass of ProtoObject is practically the same as
>being a suclass of nil, but without introducing disjoint hierarchies
>(which have some nasty effects on browsing implementors, and other
>activities that try to iterate over the classes based on the hierarchy
>using #allBehaviorsDo:).

True, but the comments throughout the image refer to ProtoObject, 
expressly discussing "disjoint hierarchies."  I think that Dan also 
made that remark in his original RFI (Request for Implementation).


>Instantiating a ProtoObject currently does crash the system (that's a
>little strong: let's say that rather that it causes the system to
>abort deliberately) because of a recursive "message not understood"
>error.

I'm willing to change the language, but I think its important to note 
that instantiating Proto-Object makes the system abort without saving 
the image.

>I personally consider this to be a (serious) bug.  Since *all*
>the subclasses of ProtoObject implement #doesNotUnderstand:,
>ProtoObject should also implement it to raise either a
>MessageNotUnderstood Error, or (much) better still a
>SubclassResponsibility Error.  At the very least, something like:
>
>    ProtoObject>>doesNotUnderstand: aMessage
>        Error new signal: 'this object cannot respond to this message'
>
>I hope some of that makes sense, and is useful.

Absolutely, but it raises a serious question of pedagogy -- do we 
continue the mantra: "everything is an Object," treating protoobject 
as a non-normal abberation of use for systems, or do we adjust our 
thinking to discuss "everything is a ProtoObject," and discuss 
non-behaving, uninstantiated objects as the "fundamental" object of 
Squeak?

Would the creation of a second hierarchy (other than classes of 
proxies) be abberant behavior, or an interesting experiment?