[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mopping up after the fact
- To: firstname.lastname@example.org
- Subject: Mopping up after the fact
- From: Jon L White <email@example.com>
- Date: Fri, 23 Nov 1990 09:30:59 PST
- Cc: Moon@stony-brook.scrc.symbolics.com, mop@arisia.Xerox.COM
- In-reply-to: "Gregor Kiczales's message of Wed, 21 Nov 1990 22:09:18 PST <90Nov21.firstname.lastname@example.org>"
re: This example is, perhaps, a bit contrived.
re: But I think it illustrates the point that make the extensible OO
protocol surrounding direct slot definition metaobjects back into
a non-extensible functional protocol is troubling.
But does it? The intent of this example would be more clearly covered
if the class metaobjects involved kept a slot for the common, defaulted
tail of a slot *specification*, which CANONICALIZE-SLOT-SPECIFICATION
would look at. Either way, of course, damages the referential
transparancy of the specification. So in a sense it might be better not
to be led into a usage that uses the re-coding of the specifications
purely in a way that demonstrates how a discrimination can be performed
upon the induced class distinction.
re: What I would rather do, actually, is change all the metaobjects
(direct and effective) associated with default initargs, into real
objects with a generic function based access protocol.
The CLOS spec (88-002R and subsequent "cleanups")) leaves the content
and type of the metaobjects unspecified; it uses "specification" or
"option" generally rather than implying a a subclassing of the resultant
"effective" metaobjects. So I would not suggest refining the concepts
found in 88-002R except where it serves a real purpose. Thus I am not
now pushing for a distinction to be made for class :default-initargs
specifications. Someday, it might turn out to be a nice idea for some
usage, but I don't feel strongly about it now.
At this time, none of the proposed nor contemplated metaobject protocols
benefit from the re-coding of slot specifications into standard objects;
and I don't think you even wanted to rebut the charge that the re-coding
makes the code and design overly complex (when seen from the viewpoint
of the proposed and contemplated protocols.) So I'm only proposing the
application of Occam's razor.
-- JonL --
P.S. [Gee, you've even gotten me saying "class metaobjects" now]