[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FLAVOR-CLASS, and Random metaclasses for CL types
re: Why not mention this directly in the standard?
I don't think it's at all appropriate to include the name FLAVOR-CLASS
in the standard. What I do want to do to the standard is to make sure
that it doesn't accidentally contain language that would make it impossible
for an implementation to add FLAVOR-CLASS, OBJECT-LISP-CLASS, PCL-CLASS,
or any of several others. I think this should be easy to do.
Uh, wrong referent on the "mention this" -- it wasn't to include FLAVOR-CLASS
in the standard. The rest of the paragraph you excerpted was:
. . . either as one possibility
for implementation of the "holy" types, or simply as an example of
an implementation-specific meta-class being used to supply one of the
The point is simply that any "implementation-specific meta-class" which
preserves the properties of the "holy" types should be satisfactory,
regardless of whether it is called a BUILT-IN-CLASS or not. The advantage
of using FLAVOR-CLASS as an example is that, like STRUCTURE-CLASS, it
is already tied into the type system of those implementations that have
it. Thus all that is lacking from CLOS's point of view is a (CLOS)
class definition stub, so that such instances may be specialized upon.
-- JonL --