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