> -----Original Message----- > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED] > 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.
Not as I recall from the paper. Especially not if the methods have different signatures. The point here being that either tree or dog may have other methods that call C<bark> internally, so the defined interface is a required list -- the only thing you can do is explicitly provide some sort of behavior modification. > > > 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 ... 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". > 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. =Austin
