Moose::Trait ?? Was: Announcement: Moose 2.0800 is released!

[email protected] (Niall Young) Mon, 9 Sep 2013 13:49:21 +1000 (EST)
Newsgroups perl.moose
Message-ID <alpine.OSX.2.00.1309091339130.12434@mel-mb002>
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
[email protected]