FLAVOR-CLASS, and Random metaclasses for CL types

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

I don't think we ever came to any resolution about your original
query of Date: Wed, 10 May 89 13:31 EDT -- namely how to rewrite
the paragraph on page 1-15 of 88-002R which spells out how the "holy"
types can be implemented.

However, I remember it being sparked by a desire to assure that
flavors-implemented types could be used as the underlying implementation
of some of the "holy" types; and this led to the discussion of how
such a class might relate to BUILT-IN-CLASS.

But I see that several vendors are planning to offer a FLAVOR-CLASS
as a tie-in with their native (or optional) flavors products (and Gregor
mentioned he is working on a similar "hook" for PCL too).  That is, a 
meta-class somewhat like STRUCTURE-CLASS that ensures that flavor types 
(which are integrated with CL types in those products) also have 
appropriately named CLOS classes behind them so that they can be 
specialized upon.

Why not mention this directly in the standard?  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.  I don't think it would be necessary to "flesh out"
FLAVOR-CLASS anymore than STRUCTURE-CLASS is currently specified.

FLAVOR-CLASS indeed has a good deal to recommend it, in an implementation
that supports flavors -- much more than, say, BUILT-IN-CLASS (see my
previous critique of the inutility of making a class for the random,
small collection of "left over" CL types).  Don't you think a short 
statement like the above would give the kind of assurance you wanted for 
Symbolic's implementation of pathnames?


-- JonL --