[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Random metaclasses for CL types
- To: Jon L White <firstname.lastname@example.org>
- Subject: Re: Random metaclasses for CL types
- From: David N Gray <Gray@dsg.csc.ti.com>
- Date: Fri, 26 May 89 12:29:50 CDT
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU, common-lisp-object-system@SAIL.Stanford.EDU
- In-reply-to: Msg of Fri, 26 May 89 08:47:17 PDT from Jon L White <email@example.com>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
- Sender: GRAY@kelvin.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)?
> User's can't
> write methods for BUILT-IN-CLASS.
Sure they can.
(defmethod frob ((class built-in-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))
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.