Re: Method Combination

["Patrick H Dussud %Jenner%ti-csl.csnet"@RELAY.CS.NET]

   Date: 28-Jan-87 15:40:00
   From: Danny Bobrow <Bobrow.pa@xerox.com>
   
       Date: 27 Jan 87 17:39:46
       From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
   
       I agree with the fact than one can define ones own
       compute-effective-method. The issue has to do with modularity.
       Compute-effective-method has to find the list of all the method
       that can be called, find the method combination method, call it to
       come up with the code for the effective method.  We need to keep
       those operations as independent as possible.  If we supply the
       information as an argument to the method combinator, the user
       writing a method combination method does not have to worry about
       how the information was obtained.
   
   I agree that finding the list of all the methods that can be called,
   finding the way to combine methods, and coming up with the code for the
   combination ought to be kept separate.  The following describes my view
   of the meta-object protocol, and how these are kept separate.
   
   The meta-object protocol for building the code for generic functions
   consists of two parts.  The top level is
   
   (compute-discriminator-code generic-function)
   
   which has as its responsibility building the code that implements the
   effect of the described four step protocol for calling a method.  Its
   usual implementation caches all the possibly different effective methods
   for the generic-function, and it produces code to decide which of these
   effective methods to call for any set of arguments.  It is this code
   that is run when the generic-function is called.  
   
   The only information compute-discriminator-code can use must be
   contained in the generic-function object.  THERE IS NO OTHER PLACE TO
   STORE INFORMATION.

I don't have problem with this, the problem is how you access it. (See
below).
   
   As a standard part of the protocol for compute-discriminator-code (which
   can be overwritten by a specialized method), compute-discriminator-code
   computes the set of applicable-methods for distinguishable sets of
   arguments, and for that set calls:
   
   (compute-effective-method generic-function combination-type
   applicable-methods)
    
   The combination-type is taken from the generic-function to allow
   discrimination on an individual (the combination type) to select a
   specialized method.  Other paramaterized information could have been
   passed in as arguments, but since that information is not being used for
   discrimination, it might as well be left in the generic function.

Ah, this is interesting. The combination type is "taken" from the generic
function by compute-effective-method, which might need the sets of
arguments you talked about earlier. But then, if you don't pass somehow
(arguments, special variable .....) all the information relevant to this
combination type, then the user has to "take" it again from the
define-combined-method code. This is not the business of the method
combination method to know how to "take" it from the generic
function. If you wonder why we would have to use the set of arguments to
compute the method combination type, you can (re)read my mail about
method combination selection that David mentioned in his last message.

I don't have time to comment on the rest of the message today. I'll hold
off until you have something more concrete on the metaclass protocol
since this is what it is all about.

Patrick.