Dependency of discriminating functions on method combinations

[Didier Verna]

Hi,

Computing an effective method depends on the generic function's method
combination. But is it also the case for computing the discriminating
function?

I don't see why it should in theory, but evidence seems to suggest
otherwise[1]. Maybe it does for technical reasons?

Thanks.


Footnotes:
[1] In SBCL for instance, flushing the effective method cache is not
enough for direct modifications to a generic function's method
combination to take effect on the next call.

[Pascal Costanza]

Hi,

Post by Didier Verna
Hi,
Computing an effective method depends on the generic function's method
combination. But is it also the case for computing the discriminating
function?
I don't see why it should in theory, but evidence seems to suggest
otherwise[1]. Maybe it does for technical reasons?

Unfortunately, method combinations didn’t get a lot of love in AMOP, which means there is not a lot you can really do in a portable way.

The discriminating function calls compute-effictive-method to determine the effective method, but is allowed to cache the results of compute-effective-method. So the only reliable portable way to ensure that new effective methods are computed is by calling add-method, remove-method, initialize-instance, or reinitialize-instance. (See the AMOP entry for compute-discriminating-function.)

This normally should mean that the most straightforward way to install a new method combination is by calling (reinitialize-instance gf :method-combination mc) - except that it’s not clear what the argument to :method-combination is supposed to look like. (It’s apparently meant to be the result of find-method-combination, except that it’s not clear what the arguments to find-method-combination should look like, especially the method combination options.)

ensure-generic-function doesn’t help either. (According to AMOP: “The handling of the :method-combination option is not specified.”)

So the next best option is (eval `(defgeneric 
)) :-}

I’m not aware of a portable way to flush caches directly in CLOS. (Some subclasses of generic-function may not even have caches
)

Pascal

--
Pascal Costanza

[Didier Verna]

Unfortunately, method combinations didn’t get a lot of love in AMOP,
which means there is not a lot you can really do in a portable way.

Yup. I'm not really interested in portability here though. I was
surprised that flushing SBCL's cache of effective methods didn't
suffice. But I may be missing something specific to SBCL...