On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote: > You mean composition. There is no "role inheritance" :)
Oops ;-)
> I'm assuming you meant
>
> class D does B does C { ... }
I always do that crap... =(
> > 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.
I think of class inheritence (mixin or otherwise) as an N-ary tree
with ordered branches. That is, if you inherit two classes, one
comes after the other.
Roles differ because the tree is unordered and all roles assimilated
into a specific consumer must be treated equally (and will thus
conflict).
This allows roles to be more reusable than classes for generic
tasks, because if there is a conflict it usually implies namespace
clashes, not extended behavior.
Making everything into flattenned set is not a feature. It can be
the way things are really implemented later, but it's a lossy
representation - information about who 'does' who is lost.
In my opinion it's better to compose all role information in the
largest chunks possible (read - as late as possible in a given
linkage/compilation cycle) for the same reasons that JIT
optimizations are more effective: you know much more. However, care
must be taken to ensure that this is not too late, to the point that
the user does not get useful information.
> 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.
The role doesn't grant trust to a class that consumes it - it simply
says "the role Foo has access to my guts when I assimilate it".
Class trust is something slightly more complex, since it's
inherited. I think that excert says "It's not clear whether roles
should be allowed to make a class trust another class when they are
consumed".
> > 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.
Really? I didn't know that... In that case roles are broken... They
will need instance data (that doesn't conflict when it's private) to
support the methods they give their consumers.
Is there any good reason to not allow roles to introduce member data
into a class?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!!!!!
pgpXvBUI05J23.pgp
Description: PGP signature
