Hi Niall, I'd love to see something like this, though the name "trait" is overloaded and I fear a name like Moose::Trait will cause confusion. Also, you wrote:
> If necessary we could always define Moose::Trait, to help implement and > preserve a fully compliant solution (e.g. no state). Not having state in traits was a mistake and the trait researchers have experimented with ways of correcting this. The reason stateless traits was a mistake is because traits often need state to track something that is completely irrelevant to the calling code, but is nonetheless necessary for the trait to do its thing. A stateless trait would then need to implement "glue code" (as it was called in the papers) to glue the trait and class together. This glue code would be duplicated in every class consuming the trait. Oops! That's something traits were supposed to avoid. Further, if the trait was later rewritten to preserve the interface but no longer needed that state, or needed the state to be structured differently, all classes implementing said glue code would need to be altered, thus killing one of the major reasons why traits were developed. In practice, they found that trait-based systems were experiencing these problems and they weren't merely theoretical in nature. If you would like to know more, email the researchers. They've been very helpful for me and their mailing list is at https://www.iam.unibe.ch/mailman/listinfo/traits. See also: * "Stateful Traits": http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf * "Stateful Traits and their Formalization": http://ulir.ul.ie/bitstream/handle/10344/2107/2008_Bergel,A.pdf?sequence=2 Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/ >________________________________ > From: Niall Young <ni...@iinet.net.au> >To: moose@perl.org >Sent: Monday, 9 September 2013, 5:49 >Subject: Moose::Trait ?? Was: Announcement: Moose 2.0800 is released! > > >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 > >
