Re: Random metaclasses for CL types

[David N Gray <Gray@dsg.csc.ti.com>]

> Hey, did you forget we are talking about BUILT-IN-CLASS (and not about
> any particular built-in class such as INTEGER or VECTOR)?  

No.

>	 User's can't 
> write methods for BUILT-IN-CLASS. 

Sure they can.

(defmethod frob ((class built-in-class))
  (punt class))
(frob (class-of 3))

There, I just did it.  The only thing you aren't supposed to do is to
replace the BUILT-IN-CLASS methods specified by the standard.  Admittedly,
the usefulness of this may be limited.

>    Since my previous arguments about the 
> artificial similarities among the built-in classes haven't been rebutted, 
> then I don't see much to be gained by trying to let them write methods for 
> such an ad-hoc construct.  

I don't see anything to be gained by not allowing it.

> In your "portable INSPECTOR" project, for example, you need to make a 
> decision as to whether to call the built-in DESCRIBE-OBJECT, or to fall 
> into some code written in CLOS.  I claim there is no conceptual
> disadvantage to making that decision by doing a MEMBER down a system
> supplied list. 

Then what do we need object-oriented programming for?  Sure, there's
always another way it could be done.

>    Furthermore I claim that creating an abstract metaclass 
> for some totally disconnected set of classes has the _disadvantage_ of 
> adding confusion, because the observer of the abstraction must think 
> that there is an underlying similarity in the base elements.

There _is_ an underlying similarity:  they share the same methods for
MAKE-INSTANCE, SLOT-VALUE-USING-CLASS, SLOT-BOUNDP-USING-CLASS,
SLOT-EXISTS-P-USING-CLASS, SLOT-MAKUNBOUND-USING-CLASS, CLASS-SLOTS,
CLASS-DEFAULT-INITARGS, CLASS-DIRECT-DEFAULT-INITARGS, CLASS-DIRECT-SLOTS,
CLASS-FINALIZED-P, as specified in chapter 3.

The only way I might accept dropping BUILT-IN-CLASS from the standard
would be if the standard included the class CLASS (which should be done
anyway), so I could do

(defmethod frob ((class class))
  (punt class))

as a catch-all for any unexpected metaclass.  But since BUILT-IN-CLASS or
some equivalent needs to exist in each implementation for the meta-object
protocol, why not standardize the name of it?  It could be argued, though,
that it only belongs in chapter 3.