[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Method Combination Objects



I have no problem at all with the Method Combination Object Layer.  It seems
just right.

Here is an alternative proposal for a "naming" layer.


There is a generic function:

(defgeneric method-combination-instance 
     (generic-function method-combination &key options) ...)

This generic function combines the capabilities of method-combination-maker and
the application of the resulting function to produce the method combination
object.  

(method-combination-instance g-fn name :options options)

is how a method combination name and options are converted into an object.

(defmethod method-combination-instance
    ((g-fn standard-generic-function)
     (name (eql '<name>)
     &key options)
    ....)
is how a method combination type is defined.

remove-method is how it is undefined.


Comparison to method-combination-maker

It has the same advantages with respect to: 

1) It provides a separate name space for method combination names.
2) Several method combination types might share a single class.
3) A call to method-combination-instance might return the same
   object each time it is called, instead of making a new object.

Advantages of method-combination-instance:

It uses a mechanism already in CLOS, namely methods on individuals, and does not
add a new function for associating a name with an object, or a way to unset that
association.

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

Disadvantage:
 As pointed out by Moon:
   The options seen in the :method-combination option to defgeneric
   are defined by a lambda-list in define-method-combination, rather
   than being just keyword arguments. ... Passing the whole
   list of options as one :options initialization argument, we wouldn't
   be exploiting any Lisp mechanism to parse the options.
As Moon points out we could change the options arguments into keywords.
Alternatively, this can be programmed around by using an application of  a
lambda-list internal to the method to check the arguments.  

In Moons message, he provides the following macro definition:

(defmacro define-method-combination
	  (name &key (documentation nil)
		     (operator name)
		     (identity-with-one-argument nil))
  `(setf (method-combination-maker ',name)
	 #'(lambda (&optional (order ':most-specific-first))
	     (make-instance 'short-form-method-combination
			    'name ',name
			    'order order
			    'documentation ',documentation
			    'operator ',operator
			    'identity-with-one-argument ',identity-with-one-argument))))


The comparable code is approximately:

(defmacro define-method-combination
	  (name &key (documentation nil)
		     (operator name)
		     (identity-with-one-argument nil))
  `(defmethod method-combination-instance
       ((g-fn standard-generic-function)  (eql ',name) &key options)
     (apply	 
      #'(lambda (&optional (order ':most-specific-first))
	     (make-instance 'short-form-method-combination
			    'name ',name
			    'order order
			    'documentation ',documentation
			    'operator ',operator
			    'identity-with-one-argument ',identity-with-one-argument))
           options)))