[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moon's comments on Draft 11
- To: jonl@lucid.COM
- Subject: Re: Moon's comments on Draft 11
- From: Gregor Kiczales <gregor@parc.xerox.com>
- Date: Thu, 1 Nov 1990 18:56:35 PST
- Cc: Moon@stony-brook.scrc.symbolics.COM, mop@arisia.Xerox.COM
- Fake-sender: gregor@parc.xerox.com
- In-reply-to: "Jon L White's message of Wed, 31 Oct 1990 20:30:52 PST <9011010430.AA18813@caligula>"
Date: Wed, 31 Oct 1990 20:30:52 PST
From: Jon L White <jonl@lucid.com>
(1) METHOD-FUNCTION is an ill-considered concept, for reasons having
nothing to do with the optimized implementations that elide it
for STANDARD-ACCESSOR-METHOD's; see comments below on "next methods"
context and APPLY-METHOD.
Yes, this is true. It is one of the things I plan to fix in this final
draft. Once it is fixed, method-function will be relevant to accessor
methods as well as other methods. That is, accessor methods will be
required to return a method that does the right thing. Most
implementations, internally, probably won't ask for it though (unless of
course they have reason to believe the user has mucked with it in some
way).
(3) Users are telling us that extensible slot-option parsing and
processing is a requirement for them; let's look at Cypher's
proposal sent out a few days ago.
I would like to see the user comments in detail. The current draft of
the MOP supports some slot option parsing. A little less than I might
have liked, but others encouraged me to ramp it down.
(4) Avoid the compile-file environment issue; pass the buck from
the MOP realm into the compiler realm.
The current draft has less than it used to. I would be glad to take
what it there out, but I was pushed to try and include it a long time
ago. I guess since then we have realized that we can't get it right.
(5) FUNCALLABLE is still too "cutsy" a syllable to be incorporated
into serious names. It's acceptable only because it isn't used.
I am reluctant to make simple name changes at this late stage.
The "STANDARD" in "STANDARD-GENERIC-FUNCTION" might simply mean
"Obeys a SLOT-VALUE protocol". I don't particularly like that
interpretation, but that is the only consistent reading of the
use of "STANDARD" I could come up with.
"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.