[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FLAVOR-CLASS, and Random metaclasses for CL types
- To: Jon L White <email@example.com>
- Subject: FLAVOR-CLASS, and Random metaclasses for CL types
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 16 Jun 89 19:37 EDT
- Cc: firstname.lastname@example.org, Gray@dsg.csc.ti.com
- In-reply-to: <8906140806.AA17033@bhopal>
Date: Wed, 14 Jun 89 01:06:07 PDT
From: Jon L White <email@example.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.
I'm not sure. I have 20 messages saved on the topic and don't have time
to review them right now.
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?
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.