Problem with closer-mop::only-standard-methods.

[pcostanza]

Problem with closer-mop::only-standard-methods.

[pcostanza]

I believe in your make-method-lambda specialization, you should just specialize the first parameter to fast-generic-function instead of just generic-function, and then it should work. :)

[marcoheisig]

No, that doesn't solve the problem. The method has been more specific already, since I have specialized the second argument on fast-method.

The problem is that the generic function make-method-lambda is never called at all, because the closer-mop specific expansion of defmethod is suppressed.

[pcostanza]

The function only-standard-methods is used to selectively bypass the invocation of make-method-lambda, because the CL-provided defmethod expansion typically can do more "extreme" performance optimization than what is possible at the MOP level. only-standard-methods only looks at the first parameter: If the first specializer is not a proper subclass of standard-generic-function, then it returns true, no matter what the method parameter is specialized on.

So, have you actually tried this? (Sorry for insisting, just trying to make sure...)

[marcoheisig]

Ah, that explanation has been very helpful. I have tried this, but I haven't specialized on fast-generic-function, but on the more generic sealable-generic-function. But this generic function is not a subclass of standard-generic-function, so the second clause of

...
(and (typep specializer 'class)
     (subclassp specializer (find-class 'standard-generic-function))
     (not (eq specializer (find-class 'standard-generic-function)))
     (typep gf specializer))
...

is false, which leads to only-standard-methods returning T. By specializing make-method-lambda on a subclass of standard-generic-function, my problem goes away.

My problem is fixed, but should make-method-lambda really be suppressed for non-standard generic functions?

PS: Many thanks for the quick replies and the helpful explanation!

[Hexstream]

As I recall, the MOP does not really specify anything about specializing on "base classes" like generic-function rather than on standard-generic-function and such.

[pcostanza]

The CLOS MOP specification is difficult to decipher when you are not working with it on a daily basis. I vaguely recall there is some restriction buried deep down in the spec which indirectly implies that specializing only on the method class does not work. That's why I also kept it that way in Closer MOP. I don't immediately see why at the moment myself. :-}

So this implies that you have to define the generic function class and the method class in tandem anyway. Since methods on specified generic functions (compute-applicable-methods, etc.) can't be "overriding" methods, but must return the same values as call-next-method, you then also get the restriction that the generic function classes have to be subclasses of standard-generic-function. (The MOP could have been more explicit about these implications, but it's amazing how much they were able to figure out and write down on paper, so we should be forgiving here... :-)

In practice, I find it quite useful to override generic-function-method-class to return the 'correct' method class for a given generic function class, then you don't have to worry about setting the :method-class option anymore in defgeneric...

Anyway, thanks for the report, it keeps my brain muscles alive. :)

Pascal

[Hexstream]

The CLOS MOP specification is difficult to decipher when you are not working with it on a daily basis.

What non-trivial software specification isn't? ;)

In practice, I find it quite useful to override generic-function-method-class to return the 'correct' method class for a given generic function class, then you don't have to worry about setting the :method-class option anymore in defgeneric...

Last summer, I thought quite a lot about new method combinations. I remember finding out that in the current regime, method classes are incredibly tightly coupled to their generic function class, thus rendering the :method-class option nearly useless in practice. I had some vague ideas about how to correct this, I don't remember the details but I'm sure I will when I work on this again...

(For now, I'm working on removing a few annoying traditional limitations with defclass and will be releasing a few MOP-related libraries soon. :))

[marcoheisig]

Thanks again, Pascal.

Should I close this issue, or do you want to throw some more brain cells at it?