[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Continuing comments on Draft 11
- To: jonl@lucid.COM
- Subject: Re: Continuing comments on Draft 11
- From: Gregor Kiczales <firstname.lastname@example.org>
- Date: Fri, 2 Nov 1990 13:19:50 PST
- Cc: mop@arisia.Xerox.COM
- Fake-sender: email@example.com
- In-reply-to: "Jon L White's message of Thu, 1 Nov 1990 22:07:46 PST <9011020607.AA20880@caligula>"
Date: Thu, 1 Nov 1990 22:07:46 PST
From: Jon L White <firstname.lastname@example.org>
Right. Andreas sent some out recently (to which email list? I can't
remember). I have received some suggestions verbally from people who
wanted to add an option which basically said "do type-checking on stores
into this slot"; there's not much more to this except the need to
be able to parse a user-specified option, and to store the result in
a user-specified field of the slot-definition. I vaguely remember
something in one of the CLOS workshop papers also, but . . .
The current MOP supports this level of slot option parsing. What it
doesn't support is saying whether a given slot option should be
evaluated, efunctuated, collected into a list, or anything like that.
Right now, all it does it carry extra slot options over, unevaluated.
I like Scott's stuff, but I would rather see it written up as a paper
that would be an improvement to this MOP than trying to get it into this
re: "STANDARD-" means the one that the user interface macros use by default.
That is, what 88-002R says they do if you don't do any MOP stuff.
Well that's an interesting view. But you can change the default for
DEFMETHOD by calling DEFGENERIC with a :method-class option, and that
step alone isn't MOP'y. It's entirely another matter to say that
you can't create any other method class without MOP, or to say that
none of the specified metaobjects other than STANDARD-METHOD and
its subclasses will be suitable.
Yes, but logically :method-class, :generic-function-class and :metaclass
belong in the MOP. Even though they are mentioned in 88-002R, 88-002R
doesn't by itself say enough about them that you could possible use them.
How about this view: ``STANDARD means "concrete"; otherwise "abstract"'',
with only a coule of exceptions (METHOD-COMBINATION and STRUCTURE-CLASS
come to mind as exceptions, but they are also exceptions to the
rule of ``"standard" means "default"'').
Probably it's only a coincidence that all three views mostly coincide
[the third being that ``"standard" means "slotted"''.]
In an email discussion in the past, I recall discussing a fatal flaw
in the design of ENSURE-GENERIC-FUNCTION -- namely the :lambda-list
argument doesn't carry enough information to be able to distinguish
the dual purposes of (a) a target of macroexpansion for DEFMETHOD and
of (b) a target of macroexpansion for DEFGENERIC. The current draft,
under the DEFMETHOD section "Processing Method Bodies" punts the issue
to ``The section "The Defgeneric Macro"''; but I can't find this section.
Did I overlook it somewhere, or is this an intentionalp lacuna?
No, the DEFGENERIC macro needs to be written, but I was planning to do
it in the way we had decided to resolve this problem.
There are six metaobject classes at or under SLOT-DEFINITION? why?
Implementationally, there isn't any need to make a class distinction
between "direct" and "effective" -- this can be done by keeping
But, direct slot definitions have readers and writers whereas effective
slot definitions don't. Also, effective slot definitions will have the
slot-definition--location stuff. They really are different, and that
difference should be recognized in their classes.
Admittedly, there is a need for a generic function
that goes through the step of taking collected direct definitions
and producing the effective definitions; but another class isn't needed.
The alternative would have at most two classes.