On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
> If, OTOH we have a diamond inheritence:
You mean composition. There is no "role inheritance" :)
>
> role A { method foo { ... } }
> role B does A {};
> role C does A {};
> class D does A does B { };
I'm assuming you meant
class D does B does C { ... }
>
> I'm not sure we need to resolve the conflict.
It depends on when composition happens. If A is composed immediately
into B and C as soon as the role is processed, then when D is being
composed, all it sees are a foo method from the B role and a foo method
from the C role.
If, however, roles aren't composed into other roles but only into
classes, then I think that
class D does B does C { ... }
would be equivalent to
class D does A does B does C { ... }
since the roles B and C would "carry" the uncomposed A role along with
them.
> > Now, since MyClass2 actually does Foo twice, does that mean &bar creates a
> > conflcit? Since &bar would be
> > found through FooBar and Baz. I would think the answer here would be no,
> > and that we would build some
> > kind of unique list of roles so as to avoid repeated consumption like this.
>
> No conflict - an assimilated role is identicle to itself even
> through different paths since it doesn't get access to private or
> protected member data of it's consuming roles.
>
> If, on the other hand, we have
>
> role X trusts Foo does Foo {
> has $:foo;
> }
Quoth A12:
It's not clear whether roles should be allowed to grant trust. In
the absence of evidence to the contrary, I'm inclined to say not. We
can always relax that later if, after many large, longitudinal, double-
blind studies, it turns out to be both safe and effective.
Has that changed?
Also, I don't think that role is something that can be trusted :)
A12/S12 only talk about trusting classes.
>
> role Y trusts Foo does Foo {
> has $:foo;
> }
>
> role Foo {
> method foo {
> $:foo++;
> }
> }
>
> class C does X does Y { }
>
> there is a conflict, because Foo is reaching into either X's private
> member $:foo or Y's private member $:foo (btw, they should never
> conflict with each other).
Er, there is only one $:foo. X doesn't have any private members, nor
does Y (because they're roles). Only C has private members. So,
modulo the multiple composition of Foo, I don't think there's a
conflict.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
