On Wed, Nov 02, 2005 at 16:37:29 -0600, Jonathan Scott Duff wrote: > On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote: > > True enough; but it needn't be true that d have the same tools > > available to resolve the conflicts that c has. > > > > There are three ways that a role can deal with a conflict: > > > > 1. choose one of a set of available methods to call its own. > > 2. create a version of its own. > > 3. pass the buck. > > > > In the first case, the question is how we define the set of available > > methods: do we make the full hierarchy of ancestors available to the > > role, or do we say that only the immediate parents are available? > > 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.
Uh, roles are composed wrt to the hierarchy of who does who. > 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. The composition is basically mixin with some exceptions, but there's still a hierarchy > 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. Class composition also happens at compile time... There's no reason to make the error occur too early for usefulness to be around. As long as it's not too late ;-) -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM: neeyah!
pgpABuzitn7pL.pgp
Description: PGP signature
