Looking at the various implementations of roles and traits it seemed the other way around in complexity based on their APIs.

This is because they are mostly experiments/toys and so there was no serious attempt to make compatible APIs between them (Perl6::Role actually states that compat is not one of it's goals). I really do not suggest using any of them, not because I wrote another implementation but because I studied all of them and spoke to their authors about them and they are not really maintained anymore.

So this -able concept could (should?) be a role or trait even if its not using the full spectrum of possibilities right now.

Sure, there is no need to use all the features of the role, a simple role as interface is very useful too.

I don't see being incomplete as an entirely bad thing. MT now makes use of YAML at ever increasing levels, but only uses YAML::Tiny for the processing. Given the complexity of the app and its installation and its prerequisites I see anything that can simplify and slim down the system as a great thing.

So while these implementations are "toys" how is their upwards compatibility with the full roles vision? If one of these classes provides enough of the functionality MT needs now, like YAML::TIny is to YAML, I don't see what it would hurt to use

In this case it is, these modules are not like YAML::Tiny is to YAML where it is a well tested and maintained subset of the functionality of a larger module. These are simply early experiments of the concept that are no longer maintained.

If you are looking for a "Tiny" Moose then you can take a look at Mouse which does not have complete role support yet, but is being actively developed and maintained and will be downward compatible with Moose roles.

Based on how I laid things out would do you think Roles in, even in the limited submit that these modules present, is better then the current multiple inheritance scheme MT is using thus far?

I think that in most cases Roles are far superior to multiple inheritance in that they do compile time conflict checking and are composed in an unordered way and so tend to be more predictable. However, they are a new concept with not too much written about them and do have a bit of a learning curve (people tend expect them to work like classes/mixins which is not how they work).

-stvn

In reply to Re^3: Sanity Check: Roles vs. Traits by stvn
in thread Sanity Check: Roles vs. Traits by tima

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.