Jonathan Worthington<[email protected]> wrote:
> Ovid wrote:
>> Though I have issues with Jonathan's approach (I don't like classes
>> silently discarding role methods as this has caused us many bugs at the
>> BBC), it's much cleaner that what I see here.
>
> s/Jonathan's approach/Perl 6's approach/ # at least, so far as I understand
> Perl 6
No; I think he meant "Jonathan's approach", as in the suggestion that
I made earlier about disambiguating by exclusion.
It occurs to me that "but" might be a way to approach this, since the
linguistic purpose of that operator is to generate a class or role
that is a slight departure from an existing role:
A but without(&foo)
might generate an anonymous role that's exactly like A except that it
doesn't have the foo method; you could then say something like:
role A { method foo() { }; method bar() { }; method baz() { } }
role B { method foo() { }; method bar() { }; method baz () { } }
class C does A but without(foo, bar) does B but without(baz) { }
I agree that there are dangers involved in excluding methods from a
role; thus my use of fairly lengthy phrases in order to accomplish it
- a sort of "handle with care" warning.
Alternatively, I could see a version of this exclusionary policy being
done through method delegation, by means of the whatever splat -
something like:
class C {
has A $a handles * - (foo, bar);
has B $b handles * - baz;
}
--
Jonathan "Dataweaver" Lang