Mopping up after the fact

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

re: Could you send a 10 to 15 line, no longer, summary of what exactly ...

The following two paragraphs lifted from the longer message are about 15 lines
total, and hit at the essence of what I was saying.  The upshot is that no 
change is implied for default initargs (since we aren't using "Initializer"
objects); but the extra kinds of <mumble>-SLOT-DEFINITIONS could go away 
(leaving primarily one) if we chose not to recode the storage of canonicalized
slot  _specifications_  from lists into standard-object instances.  The rest 
of the message was rebutting the hypothetical argument that it could be useful
somewhere, someday, to have done the recoding.


   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

*** Only the one function *** -- COMPUTE-CLASS-DEFAULT-INITARGS -- ever looks 
at the "direct" default initarg specifications; and in some cases it would be 
premature to classify them into Initializer classes until FINALIZE-INHERITANCE
is called on that class.  The natural course is to leave the "specifications"
in their list-structure original format, and to let the function invoked at 
inheritance finalization time be the sole one responsible for collecting the 
pieces of spec into a full, effective "definition."

Just as in the case of the :DEFAULT-INITARGS specifications,  *** only the one
function *** -- COMPUTE-SLOTS -- ever looks at the "direct" slot specifications
and in some cases it might be premature to classify them into final 
SLOT-DEFINITION sub-classes until FINALIZE-INHERITANCE is called on that class.
The natural course is to leave the "specifications" in their list-structure 
original format, and to let the function invoked at inheritance finalization 
time be the sole one responsible for collecting the pieces of spec into a full,
effective "definition."

   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 


-- JonL --