[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FLAVOR-CLASS, and Random metaclasses for CL types
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: FLAVOR-CLASS, and Random metaclasses for CL types
- From: Jon L White <email@example.com>
- Date: Wed, 14 Jun 89 01:06:07 PDT
- Cc: firstname.lastname@example.org, Gray@dsg.csc.ti.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
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 --