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

Understanding Method Combination.



As far as I know the MOP doesn't provide a way for a tool to find out
about combined methods in a way in which the user/environment tools
might be interested.  Method call sequence/behaviour is very important
to being able to understand what's happening in a program.  What I'd
like to propose is the following MOP function (I don't care what its
name is, the functionality is what counts):

Combined-Method-Pseudo-Code (GF &rest specializers)		[Function]

This function is passed a generic function and a collection of
classes that denote the classes of the arguments that are to be
passed to the generic function.  It returns the lisp code for the
combined method's body but with the actual code that invokes the
actual methods replaced by the method objects themselves.  Thus
in the following example:

(defclass container () ())

(defclass bottle (container) ())

(defclass sauce () ())

(defclass ketchup (sauce) ())

(defmethod fill ((me container) with) ...) ;;; vanilla primary method.

(defmethod fill ((me bottle) (with sauce)) ...) ;;; New primary method.

(defmethod fill :after ((me container) t) ...) ;;; Make sure we don't overflow.

(defmethod fill :before ((me container) t) ...) ;;; Make sure lid's open.

(defmethod fill :after ((me bottle) (with ketchup) ...) ;;; 57 varieties.

(defmethod fill :before ((me bottle) (with sauce)) ...)
   ;;; Make sure we're upright.


...

(Combined-Method-Pseudo-Code #'fill (find-class 'bottle) (find-class 'ketchup))


->

  (progn #<Standard-Method (method fill :before (bottle sauce))>
         #<Standard-Method (method fill :before (container t))>
         (multiple-value-prog1
           #<Standard-Method (method fill (bottle sauce))>
           #<Standard-Method (method fill :after (container t))>
           #<Standard-Method (method fill :after (bottle ketchup))>))

I've implemented this sort of functionality once already and it works
just fine, but it's horrible stuff.  This is the sort of thing that an
implementor could do easily and a user currently cannot do in any
system independent way.  It clearly doesn't matter that the code body
for the combined method could contain system dependent forms, since
all we want to be able to do is understand what's going on.

Does this sound reasonable?



Rice.