[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Method Combination Objects
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Method Combination Objects
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 27 Jan 88 16:01 EST
- In-reply-to: <880127111739.7.GREGOR@SPIFF.parc.xerox.com>
Date: Wed, 27 Jan 88 11:17 PST
Basically, I agree with all your suggestions. Details below.
Dick and/or Linda: if you want me to send out a revised version of what
I just sent out, with Gregor's suggestions incorporated, please let me
know. Otherwise I'll assume that you'll do the merging.
First off, I really don't like the name method-combination-instance. I
think it should be method-combination-object.
I agree. This doesn't affect chapter 1 or 2.
I would prefer the order of arguments: [for compute-effective-method]
(<generic-function> <method-combination-object> <methods>)
I agree. This affects chapter 1.
Since method-combination-instance (method-combination-object) must be
called before ensure-generic-function is called, its first argument is
actually a prototype of the generic function.
On 13 January, Danny said
[method-combination-instance] allows specialization on the class of
the generic function as well as on the name. Although useful, this
might not be important because compute-effective-method also allows
specialization on both the generic function and method combination
Given this, and what you just pointed out, I think it was a mistake to make
the generic function an argument here. Thus I think the arguments should
be (method-combination-object name options) => object. This doesn't
affect chapter 1 or 2.
Also, are you proposing that once a generic function has a method
combination object it is not possible to extract that object from it?
What exactly happens with the :method-combination argument to ensure
generic function? It seems to me that argument should be stored away
`inside' the generic function and that it should be possible to extract
it and modify it. This would mean that there would be an accessor for
generic function called something like
generic-function-method-combination-object. It would also mean that
method-combination-object should return a new object each time and that
perhaps it should be called make-method-combination-object.
I agree with all this. I said somewhere in my message that the
existing chapter 3 accessors for generic function objects need to be
adjusted, but I didn't try to give any details since I don't have
access to the current version of chapter 3. Anything that returns the
method combination name or options, given a generic function, should
be removed, and something that returns the method combination object,
given a generic function, should be added. This doesn't affect
chapter 1 or 2.