FLAVOR-CLASS, and Random metaclasses for CL types

[Jon L White <jonl@lucid.com>]

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
    "holy" types.  

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 --