Austin Hastings writes:
> > Hmm. The text and examples so far have been about methods and this
> > seems to be about multi-methods. Correct me if I'm wrong ...
>
> You're wrong. Consider my example, where via single inheritance we reach a
> "layered" list of methods, each of which replaces the previous one in the
> namespace (parent.method superseded by child.method). This is not
> multi-dispatch -- the class of the object being dispatched determines the
> method -- but I want to modify the dispatch chain so that some upstream
> class' method is "ignored".
It's surely possible by modifying that class's DISPATCH.
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
And by "good", I mean that the following pattern should not match
against it:
/:i foo | bar | baz | quux | animal | mammal | vehicle | car | yacht /
> > That's not how I interpretted "forget" It looked more like "this method
> > doesn't exist, please error now". Which you can achieve by providing a
> > an ordinary method that just errors. However, if you wanted to control
> > how the method is dispatched, that's exactly what .DISPATCH() is for.
> > (assuming .DISPATCH is writ in something resembling stone as I only
> > recall seeing it mentioned once or twice) Just write it so that it
> > doesn't consider the multi-method you want to forget.
>
> See above. I'm willing to believe that a module could be done that provides
> this service in the way you describe, if it can be temporized.
Yep. For a weekend or a week, there's nothing like DISPATCH. Food, fun
and fashion, DISPATCH is your match. :-p
Luke
> =Austin
>
