Method Combination Objects

[Gregor.pa@Xerox.COM]

    Date: Wed, 27 Jan 88 12:34 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    There haven't been any dissenting comments, as I assume the design for
    method combination meta objects agreed on by Danny and me is accepted
    by everyone else.

I have just a few problems with this.  I have included only the parts of
your message I have problems with, all the other parts are just fine.

First off, I really don't like the name method-combination-instance.  I
think it should be method-combination-object.  I think the sentence "A
method combination instance is a meta object which..." shows why this
name is better.  We call methods "method objects" and classes "class
objects" etc.

    First, the impact on chapters 1 and 2.  Page numbers refer to the 20 Jan
    1988 drafts.

    1-33 last paragraph (excluding the implementation note), second sentence.
    Replace this sentence with:
     "The generic function {\bf compute-effective-method} receives as
      arguments the generic function, the sorted list of applicable
      methods, and the method combination instance."

I would prefer the order of arguments:

  (<generic-function> <method-combination-object> <methods>)

When its clear that only some arguments are intended to be specialized,
I like putting them up from.  Also, those two arguments are the ones
that are going to consiper to work on the third so I like that order of
arguments for that reason too.

    2-43 ensure-generic-function arguments: Nothing really needs to be
    changed, since the value of the :method-combination argument is not
    described at all in the latest draft.  However, I suggest two sentences
    should be added:
      "The {\bf :method-combination} argument is a method combination
      instance.  A method combination instance is a meta-object that
      encapsulates the method combination type and options specified by the
      {\bf :method-combination} option to forms that specify generic
      function options."

    Method Combination Naming Layer

    This layer is concerned with mapping method combination names and
    options, as seen in the :method-combination option to defgeneric, to
    method combination meta-objects.

    (method-combination-instance generic-function
				 method-combination-name
				 method-combination-options)
	       => method-combination

	is how a method combination name and a list of options are converted
	into an object.  define-method-combination expands into a defmethod
	for method-combination-instance.  remove-method can be used to
	undefine a method combination type.

	method-combination-instance signals an error if
	method-combination-name is unrecognized.  Each method for
	method-combination-instance signals an error if the
	method-combination-options are unrecognized or there are
	too many or too few of them.

	method-combination-instance might return the same object each time
	it is called with given arguments, or it might make a new object.

    (method-combination-name method-combination) => symbol
    (method-combination-options method-combination) => list

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.

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