Jonathan Worthington<> 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

Reply via email to