Method Combination Objects

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 27 Jan 88 11:17 PST
    From: Gregor.pa@Xerox.COM

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
  object.

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.