I find your terminology a bit confusing. There are Perl 6 "traits", then there are Perl 6 "Roles", which are somewhat based on the ideas in the Traits papers.

I don't really see Perl 6 traits as being all that much like Mix-ins though. Personally, I am not so sure what Perl 6 traits will be most useful for. The Apocolypse says:

A class declaration may apply various traits to the class. (A trait is a property applied at compile time.) When you apply a trait, you're accepting whatever it is that that trait does to your class, which could be pretty much anything. Traits do things to classes. Do not confuse traits with roles, which are sworn to play a subservient role to the class. Traits can do whatever they jolly well please to your class's metadata.

It sounds to me like a place where only the genius or the insane will venture (at least regularly). Either way, I am still not 100% sure what good they will provide other then to implement "deep-level" things like AOP, or to replace the "symbol-table-hacking" stuff. But I am not even sure about that, of course if anyone cares to enlighten me, it would be much appreciated.

As for Perl 6 Roles, these I feel are more akin to Mix-ins, although not quite really. From my (limited) understanding, Perl 6 Roles will really be a fancy way to set up a delegation-type relationship between classes and Roles (which I see as being partial or deffered classes). This is very different from the Traits idea it was originally based upon (which in some ways are very much like Mix-ins, just with a clear set of rules and a means to enforce them).

Confusion over terminology aside, I would like to comment on some of what you list as problems for "mixins, traits, etc":

be universally usable

I don't believe this to be true, and IMO one of the reasons why things like this get a bad wrap. Any experienced OO programmer knows that you have to know when to say when, or you end up with the God-Object-Uber-Base-Class-From-Hell. It is highly unlikely that you can create mix-ins or traits that can be all things to all classes. At some point you need to weigh the benefits of code-reuse vs. code-complexity. When it really comes down to it, polymorphism a more powerful means of code-reuse anyway.

I would recommend reading this Traits paper to see how they refactored the Smalltalk Collection hierarchy with Traits. It shows that building Traits, should not be treated as just building small, incomplete classes to be squished together at a later time, but instead a rethinking of how classes are/can be composed. Its very informative, and likely relevant to how one might use Perl 6 traits/Roles as well.

Keep in mind, that there is nothing in the Traits rulebook that says you cannot implement a Trait with no methods and only requirements (which amounts to the equivalent of a Java interface). And I would expect that Perl 6 Roles and traits works that way too.

avoid namespace clashes

Well, I imagine Perl 6 traits, being compile-time beasts, will not even allow this. Perl 6 Roles have means of working around this by fully qualifying the name. And Traits are much like Perl 6 traits in this, in that there are rules to govern namespace conflicts and they will all either be resolved at compile time, or just not compile.

Comparability and equality
~snip~
There is such an instance that is identical except for the difference in their traits.
Is it the same?

I would argue that they are clearly not the same instance, but that it not to say that they are not equal to one another. Maybe I am misunderstanding you, but I see determining comparability and equality as not really having to do with the concept of "mixins and traits" and more having to do with the requirements of your specific application. For some classes equality may be their UUID, for others, it is equivilant internal data, its really all about what you want to do with it. Again, maybe I am misunderstanding you here, please correct me if I am.

In the end, all these things (Perl 6 traits, Perl 6 Roles, Traits (ala the papers)) are still toys. And much as dragonchild points out, they will be feared initially, and if they prove useful, will eventually become accepted parts of how we all code OO. Even after having written Class::Trait, I have yet to find a real good use for it, other than something to play around with. And I am waiting on either Class::Roles or Class::Role to see how Perl 6 Roles might be useful, and I suppose I will need to wait for Perl 6 itself to see how Perl 6 traits might play out.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.