Jonathan Scott Duff wrote:
> People keep using the word "hierarchy" when talking about roles and I
> keep thinking that it is the one word that definitely does NOT apply.
> Heirarchies are for classes and inheritance relationships, not roles
> and composition.
>
> In my world view, a role that is composed of two other roles has full
> view of the methods/attributes defined in the roles that compose it
> because the landscape is quite flat. There are no hills and valleys.
> When it finally comes down to composing into a class, the class sees
> all of the methods/attributes provided by each and every role even the
> role inside a role inside a roles.
-snip-
> When you say:
>
> role A { ... }
> role B { ... }
> role C does A does B { ... }
> role D does C { ... }
>
> roles A and B are composed into C at compile time. If both A and B
> define a method foo(), then there is a conflict (immediately, at
> compile time) unless you've somehow told perl that it should defer
> composition until it's actually composing classes.
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
--
Jonathan "Dataweaver" Lang
