Re: method-lambda and apply-method-lambda

[Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>]

     We have to find some way to converge on this soon.  My basic point is
     that the genericity should be at the level of add-method and
     compute-discriminator-code and that at the level of making method
     functions and calling method functions the code should not be generic.

I don't understand your position here. 

Here is the issue the way I see it:

- The fact that a generic function calls an effective method establishes a
contract between these two entities.

- This contract has to be abstracted  because the implementor should be free to
optimize this time critical operation.

- We want to give access to this operation, namely one wants to call a method
that
belongs to a generic function, with its own set of arguments, with his own set
of next methods (apply-method-lambda).

- We want to give programmers the use of (setf method-function), which is
concerned by the above contract (make-method-function).

In 88-003 the following pieces are connected to this contract besides 
apply-method-lambda and make-method-function:

- Compute-discriminator-code, whose result is a piece of code,which when executed
does the method lookup and the calling of the effective method function object.

- Add-method is connected to this protocol because it needs to make sure that
the method added to the generic function will fulfill its part of the contract.

Add-method and compute-discriminator code are generic.  Add-method behavior (
deciding if a method is acceptable to the generic function) is implemented by
specialized methods.  Compute-discriminator-code will implement its part of the
contract with specialized methods.  Now you tell me that the other portions of
the pieces connected to the contract should be wired in for standard-method and
standard-generic-function, and there is no standard way to call a method,
compatible with a generic function, if the method is not a standard-method and
if the generic function is not a standard-generic-function.

I strongly object to this attitude because:

One implementation can define a new pair of (generic-function, method) that have
their own contract (In theory, you write a method on compute-discriminator-code
and add-method), but any portable code that would want to call such a method
would fail because they are using the wrong function. Worse, a user has NO WAY
of telling if he can use apply-method-lambda on a (generic-function, method)
pair, unless: 
(and (eql (class-of generic-function) 
          (symbol-class 'standard-generic-function))
     (eql (class-of method)
          (symbol-class 'standard-method))) is true.
	
In my opinion, it breaks one of the goals of the metaclass design:
One can write some portable tools that can use the introspection capability of
MOP.

We may as well forbid any specialization of standard-generic-function and
standard-method.

Patrick.