[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: find my slot
- To: jonl@lucid.com
- Subject: Re: find my slot
- From: Gregor Kiczales <gregor@parc.xerox.com>
- Date: Fri, 30 Nov 1990 11:19:15 PST
- Cc: Moon@stony-brook.scrc.symbolics.com, davis@ilog.ilog.fr, mop@arisia.Xerox.COM
- Fake-sender: gregor@parc.xerox.com
- In-reply-to: "Jon L White's message of Thu, 29 Nov 1990 14:58:36 PST <9011292258.AA01506@caligula>"
Date: Thu, 29 Nov 1990 14:58:36 PST
From: Jon L White <jonl@lucid.com>
However, FIND-CLASS and FIND-METHOD are "Chapter 2" facilities. Would
you now propose to remove FIND-METHOD? or would the uniformity of
interface resulting from the addition of FIND-SLOT-DEFINITION be
better than trying to retrench into a minimal kernal language?
Just to agree with (part of) what David said. FIND-METHOD may appear in
88-002R, but it is pretty clear to me that it is really a (simple) MOP
facility. 88-002R mentions a few things that lets users get their hands
on metaobjects, and says that there are things called metaobjects. But,
it doesn't say enough, by itself, to do anything with them.
This isn't a proposal to change anything about 88-002R. I just want to
point out that I don't believe the "88-002R"/"MOP Document" distinction
lines up perfectly with the "CLOS (The Base Language)"/"MOP (The Meta
Language)" distinction.
As an aside, I think we should add FIND-SLOT-DEFINITION. Sure, it is
simple to write, but so is UNION. Also, I think it and FIND-METHOD
should be/remain generic. As David pointed out, this makes it possible
to have them be more efficient in certain cases, which is, I believe,
not negligible.