class-prototype

[Jon L White <jonl@lucid.COM>]

re: The description of class-prototoype seems refreshingly short. 

Time will tell whether shortness is "refreshing" or is indicative of 
a limited exposure to the consequences.


re: Don't expect anything else like its slots being bound, or it
    having gone through any part of the make-instance protocol.  Should
    this be clarified?

The fact that a prototype cannot be "made" until the class's 
superclasses are defined means that it must submit to some kind of 
lazy creation.  This fact alone has caused concern with end users who 
managed to observe the "birth" occuring at unexpected times [e.g., John 
Rose at Sun.]  This *might* be why someone would want to relax the 
requirements on the properties of the object returned by CLASS-PROTOTYPE.

An alternative is to create bogus objects that simply carry type 
information; they would at least obey the strictures you just quoted
from the PCL mailing list.  Unfortunately, this is a gross violation of 
the contract with data typing, so it's not clear that exposing such 
bogons to the end user via CLASS-PROTOTYPE serves any purpose, even 
though implementations might make efficient use of it in some circumstances.

Because ALLOCATE-INSTANCE got accidentally left out of the 88-002R,
I don't recall whether the restriction laid on MAKE-INSTANCE is also
laid upon ALLOCATE-INSTANCE; it probably should be (i.e., you can't
allocate an instance until the class and its supers are "defined").
Even though ALLOCATE-INSTANCE doesn't put values in slots, their
presence is "first class" due to SLOT-EXISTS-P; thus the reasoning
behind the restriction on MAKE-INSTANCE applies exactly here too.

It's entirely another matter as to whether or not it makes sense
to relax the restriction on MAKE/ALLOCATE INSTANCE  --  I've had
numerous question about this one from folks who are accustomed to
the use of KEE.  Implementationally, it is easy enough to do, but
there are serious questions as to what the semantics for such bogons
ought to be (other than their datatype, that is), especially with
respect to signaling an error when the lack of defined superclasses
is a clear impediment.



-- JonL --