[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 <jonl@lucid.com>
- Date: Thu, 25 May 89 09:36:33 PDT
- Cc: dussud@lucid.com, Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: David N Gray's message of Wed, 24 May 89 17:35:33 CDT <2821041333-6833702@Kelvin>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
re: Date: Wed, 24 May 89 17:35:33 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
. . .
[... jonl's inheritance diagram for FUNCTION, STANDARD-FUNCTION, etc]
. . .
OK; the real issue is that if users are to be permitted to define
subclasses of GENERIC-FUNCTION or STANDARD-FUNCTION, then they just need
to know what to use for the :METACLASS option for their class in order
for the inheritance to be permitted.
Right. And I don't see any particular reason to require it to be
STANDARD-CLASS. But even if it were to be STANDARD-CLASS, that's not
nearly so important as the recognition that subclass relations in the
base classes -- such as FUNCTION, STANDARD-FUNCTION, and
STANDARD-GENERIC-FUNCTION -- don't imply any particular subclass relations
in their metaclasses. I think you seem to be agreeing with me on that.
re: Date: Wed, 24 May 89 18:34:43 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
. . .
[suggestion that specification for the "holy" types must explicitly
allow for STANDARD-CLASS and STRUCTURE-CLASS because of the
openness of CLOS]
. . .
I don't see why flavor classes are any different from standard classes
in this regard. Our implementation provides for writing CLOS methods
that specialize on flavors and use SLOT-VALUE to access their instance
variables. True, flavors does have another way of writing methods that
can be used instead, but that wouldn't necessarily be true of all
implementation-defined metaclasses.
With respect to STANDARD-CLASS, that's precisely the point -- that there
are _no_ ways other than SLOT-VALUE, etc. [I presume you meant "all
implementation-defined metaclasses" for built-in classes?] But you're
clever trick for pathnames -- letting it be implemented by a kind
of standard class ("hidden-class") but represented by a kind of built-in
class (the "visible-class") -- shows that we could even forgo the
special dispensation for STANDARD-CLASS and STRUCTURE-CLASS.
However, if the Gabriel plan of flushing BUILT-IN-CLASS succeeds, it
will all be moot.
-- JonL --