call NO-APPLICABLE-METHOD in the appropriate place
Otherwise we end up with NO-PRIMARY-METHODs. We should only compute
an EMF if there are in fact some methods, or at least that seems to be
the current behaviour of SB-MOP:COMPUTE-EFFECTIVE-METHOD-FUNCTION
it was actually mostly done internally to PCL, in the effective method
computation. However, for probably tedious historical reasons, the
way that this is actually implemented involves binding a magical
special variable at the point that the effective method form is turned
into code, which we weren't doing. Now we are.
get SPECIALIZER-DIRECT-METHODS (and -GENERIC-FUNCTIONS) right
we can do what we need by having SB-MOP:ADD-DIRECT-METHODS and
SB-MOP:REMOVE-DIRECT-METHODS maintain a per-class table, indexed by
the specializers under SB-PCL::SAME-SPECIALIZER-P, of direct methods.
This then is agnostic to whether the specializers are interned or
freshly generated.
Make CALL-NEXT-METHOD cause an irrevocable control transfer: returning
from any primary method returns from all of them. (Because
media-types are basically disjoint, it doesn't really make sense to
have CALL-NEXT-METHOD return).
A handy example to do dispatch based on the Accept: header in
HTTP requests. Includes a tricky method combination which
in addition can set the Content-Type: header of the response.
We need arbitrary generalizer objects, not least so as to have
composable specializer functions (if we want generic functions
which can have more than one extended specializer class, we need
to be sure that our generalizers won't stomp on each other).
But that means that cacheing effective methods depends totally on
interning generalizers, which is a bit lame, unless we ask the
extended specializer implementor to provide a subkey to be used
in the key to the emf cache. This new protocol function is a hook
for exactly that purpose.
(Minimally update the cons specializer example: it's still bad, in
that it uses symbols as the generalizer for conses, but the protocol
in principle at least doesn't leak now.)
Include some generic function arguments for specialization in protocol
functions involving generalizers. (Otherwise there are some cases where
it's not possible to define methods not in violation of the rules about
specializers applicable to instances of not-standard classes.)
Adjust the CONS-SPECIALIZER example to suit, and include an extra test
case which shows of method-combination as well as the new ability to
have multiple applicable methods with class specializers.
I think it's practically impossible to do on our own, certainly
efficiently: handling the pseudo-lisp that is an effective method is
likely to go wrong. Piggy-back on SBCL, with
SB-PCL::MAKE-EFFECTIVE-METHOD-FUNCTION and SB-PCL::INVOKE-EMF
Lightly modified on a first read-through, mostly cosmetic though with
the innovation of the GENERALIZER concept, as in
COMPUTE-APPLICABLE-METHODS-USING-GENERALIZER and
SPECIALIZER-ACCEPTS-GENERALIZER-P. Lots of FIXME notes for the things
that weren't trivial.
projects / specializable.git / log