[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Random metaclasses for CL types
- To: Gray@dsg.csc.ti.com
- Subject: Random metaclasses for CL types
- From: Jon L White <firstname.lastname@example.org>
- Date: Sat, 27 May 89 13:54:10 PDT
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU, common-lisp-object-system@SAIL.Stanford.EDU
- In-reply-to: David N Gray's message of Fri, 26 May 89 12:29:50 CDT <2821195790-16113736@Kelvin>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
re: [using MEMBER on a list of built-in classes]
Then what do we need object-oriented programming for? Sure, there's
always another way it could be done.
That's not the point at all; rather the entire issue is whether or not
BUILT-IN-CLASS has enough commonality among its elements such that
writing methods on it makes sense (your example method certainly didn't
make any sense to me). The flip side of the comment "Sure, there's
always another way it could be done" is, "Sure, every random collection
of things can be made into a class".
I am certainly not arguing against someone implementing built-in classes
this way -- using a common meta-class to simplify coding -- rather, I am
supporting Gabriel's call to remove this piece of non-portable, internal
implementation from the end-user's view.
re: There _is_ an underlying similarity: they share the same methods for
MAKE-INSTANCE, ... CLASS-FINALIZED-P, as specified in chapter 3.
I.e., they are "similar" because someone decided make a random collection
of types, and then list all the methods that could be applied to class
objects? Isn't that circular reasoning? [By the bye, Chap 3 *isn't*
part of the standard, and we are talking about a change to the elementary
part of Chap 1.]
Also, as I would have it, built-in classes couldn't be defined by the
user, subclassed by the user, dynamically altered by the user, etc;
under these restrictions, many parts of the metaobject protocol wouldn't
be interesting for random collections of built-in classes, including the
whole such collection.
In fact, _almost_ any method that one would need to support the
implementation of built-in types is not specific to BUILT-IN-CLASS,
but is the default at the top of the class heirarchy. The restrictions
on BUILT-IN-CLASS are typically just "You can't do that", which is
what you need for any otherwise unembellished metaclass.
re: 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), . . .
Gleep, I don't recall how we managed to vote in Chap 1 without class CLASS.
Can someone add a quickie cleanup to straighten this out?
-- JonL --