On Thu, Jan 29, 2004 at 10:54:18PM -0500, Austin Hastings wrote:
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[EMAIL PROTECTED]
> >
> > Actually, no; roles don't _need_ "suppress" or "rename" options to
> > disambiguate a conflict: the priority chain of "class methods, then role
> > methods, then inherited methods" provides all the tools that are
> > _required_ to remove ambiguities: you merely override the conflicting role
> > methods with a class method - which may explicitly call the preferred
> > inherited or role method, do its own thing, or both. This technique
> > covers every benefit that exclusions and aliases provide with the sole
> > exception of the ability to make a given method name unavailable. Its
> > only other potential fault vs. suppress and rename is poor Huffman
> > encoding.
>
> This is not my understanding. If I say
>
> role tree {
> method bark {...}
> }
>
> role dog {
> method bark {...}
> }
>
> class Trog
> does tree
> does dog
> {
> ...
> }
>
> then there is a conflict unless an alias is declared, or unless the class
> explicitly specified which method to call, or provides a combining method.
>
> But saying
>
> class Trog
> does tree { forget bark() }
> does dog
> {
> ...
> }
>
> makes it pretty clear what's happening.
Doesn't
class Trog
does tree
does dog
{
method bark { ... }
}
Also make clear what's happening? Especially when the ... isn't
literal, but really a call to tree.bark or dog.bark.
> > It's been suggested that something like this could be handled by hacking
> > the DISPATCH method of a class so that it throws an exception whenever
> > that method gets called. This doesn't really _remove_ the method in
> > question, but it does render it unavailable (implicitly, at least).
>
> Yes, but I don't want an exception. I want an "ignoration" -- possibly
> causing the dispatcher to locate some other, less proximate, candidate
> method.
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 ...
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.
You can also control how closely a multi-method matches by choosing an
appropriate method signature. For instance, an unprototyped
multi-method would sit at the bottom of the list with prototyped
multi-methods before it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
