Austin Hastings wrote:
> Jonathan Lang wrote:
> > 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.
Which doesn't contradict what I said in the slightest. We agree that the
class needs to include _something_ to disambiguate the two versions of
"bark"; we're only differing in terms of what it is that needs to be
included. What I'm saying is that
class Trog
does tree
does dog
{
method bark {tree.bark;}
}
would suffice, due to the fact that class methods take precedence over
role methods. It's a bit wordy (and gets moreso as you add a signature
and use longer method names), but it does the trick. Give this technique
an abbreviated form that removes as much of the redundancy as possible,
and you've got something that rivals the "exclusion" and "alias"
alternatives in brevity:
class Trog
does tree
does dog
{
method bark is from tree;
}
> But saying
>
> class Trog
> does tree { forget bark() }
> does dog
> {
> ...
> }
>
> makes it pretty clear what's happening.
True. It just isn't _needed_.
Don't get me wrong: I don't neccessarily have anything against the
inclusion of a "forget"/"exclude"/whatever technique; I'm merely arguing
that such a technique isn't something that we can as yet assume that perl
6 will have - and the only functionality that we lose by not having it is
the ability to render a method completely inaccessible via implicit calls.
Is this functionality _really_ that important to have?
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
