On Thu, 28 Mar 2013, Ovid wrote:
I noticed this in the change in behavior:
* Roles can now override methods from other roles they consume directly,
without needing to manually exclude them (just like classes can). (mst)
Have there been issues reported as a result of the previous behavior of roles?
In the paper "Traits, a formal model" (which is actually rather easy to read and I highly
recommend it - http://scg.unibe.ch/archive/papers/Scha02cTraitsModel.pdf), the very first
proposition (cunningly named Proposition 1) guarantees that "Symmetric composition is
associative and commutative." This was intended to be one of the strengths of traits vis-a-vis
inheritance and mixins. There are already a few cases in Moose where this no longer holds (some of
which may have been oversights), but now we're even more clearly discarding the associative
guarantee.
<snip>
The associative and commutative guarantees are the primary mechanism that
traits use to overcome the limitations of MI and mixins. I should be able to
mix-and-match my roles at will without worrying about breaking my contract with
the consumer.
I'm certainly interested in preserving alias and excludes as-is, to
implement _Traits_ as designed. Moose's implementation isn't close to
being compliant unfortunately, so I'm focusing on identifying the
sub-set of features which gives me Traits, or gets me as close to it as
possible.
If necessary we could always define Moose::Trait, to help implement and
preserve a fully compliant solution (e.g. no state).
Has anyone gotten their Traits implementation close-to or compliant with
the paper? I've been exploring a few MooseX but everything so far
has not been Trait compliant, with state dependencies or other
complications which make re-using features via Traits all but
impossible.
--
Niall Young
ni...@iinet.net.au
