Me wrote:

> I can imagine plausibly useful dispatch rulesets that do not involve
> comparing sums of inheritance distances. (Though this *is* all
> imagining as I haven't used multimethods/clos in about 10 years.)
> 
> I would also imagine that others see that summing inheritance
> distances may not be the only intelligent way to pick among
> candidates when a perfect fit is not available.

One stupid but simple system would be, take the best fit on
the first argument, then choose from among remaining variants for
second argument, repeat for all arguments.

Combined with an easy syntax for duplicating all possible calls
for purposes of matching on the second or nth argument, or at least
a tool for listing all the prototypes, for development purposes.

That could get ugly though.


dispatching a call with N typed arguments could be considered as
selecting a cell from a sparsely filled array in N-space.  In keeping
with the idea of virtual tables, the N-block could be completely filled
at routine registration time. Which means we would need a prototype
language that says which cells in N-space to take.  Maybe a parameter
to indicate "match strength" 


or multiple prototypes for the same routine:

        sub handle
           (normal_window $w, resize_event $e)
           (contrived_resizing_window $w, event $e)
        {
                $w->set_size(e->get_size);
        };

combined with a shorthand for generating lots of available prototypes

        sub handle
           (*_window $w, kill_event $e)
        {
                $w->kill();
        };


At some point during last year's discussions (possibly a year ago this
week, who knows) there was discussion of making the prototypes
match based on regular expression match against the names of the
types of the objects.  That would be a mechanistic approach to
implicitly filling the N-block.  I believe it was left out of rfc97
due to incompleteness of the specification.



 
> Even if the dispatcher is the heart of multimethods, perhaps it
> would be nice if it were convenient to replace the dispatcher
> in whole or part. 

If the dispatcher is drop-in replacable, what does its interface
look like?  How much information is it allowed to gether from the
source code?  Do we even want to support one specific one rather
than what we can do in '5 which is set up a special package
where multimethods live and have each one start off with its
dispatch routine?


        multimethods::handle($w,$e);



-- 
                                           David Nicol 816.235.1187
                                       KAK OH CKA3AT "what he said"

Reply via email to