On Oct 28, 2005, at 11:38 AM, Jonathan Scott Duff wrote:
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.
Personally, I think the later makes the most sense. This fits very
well with the "roles are just containers" idea. A role flattens
method, attributes, *and* subroles too.
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?
To quote $Larry[0] "A12 should be read for entertainment purposes only"
I know, that scares me too ;)
Stevan
