Sanity Check: Roles vs. Traits

[tima]

What is the difference between a Role and Trait? I've read the CPAN docs and even some of the academic papers trying to get my head wrapped around this stuff.

Reason being I'm active in the MTOS (Movable Type Open Source) community and the discussion about "whatever-able" classes comes up occasionally and whose use is growing.

Let me explain what I mean by "whatever-able" classes in how they are used in MT.

It started off as Taggable (object can be tagged), then Scorable (object can be rated or scored) was introduced and now there is discussion of others like comments and categories. The thing is these "whatever-able" classes are designed that your data object must inherit them which usually means multiple inheritance. It also means only the developer of the object class has the option of making an it taggable etc. So if I'm doing some consulting and the client needs a blog object to be taggable and it's not (not yet so far) I'm out of luck or I could trying some nasty hacking that is sure to break later when new versions are released.

After reading about roles and traits it seems one of these approaches is the saner/better way to go especially since modularity and flexibility and extensibility are cornerstones of MT going forward.

Here are some samples classes from MT to give you some code to look at:

• http://code.sixapart.com/svn/movabletype/branches/mt4.21/lib/MT/Entry.pm
• http://code.sixapart.com/svn/movabletype/branches/mt4.21/lib/MT/Taggable.pm
• http://code.sixapart.com/svn/movabletype/branches/mt4.21/lib/MT/Scorable.pm

So I need a sanity check and thought I'd post something here. Correct me if I'm wrong.

• Would what MTOS is calling taggable, scorable qualify as a role or trait? I'm thinking yes, but the examples I've seen don't quite fall inline.
• Roles seem to be a more simple and basic implementation of the traits idea.
• Traits includes more advanced features like overloaded operators, required method labels, conflict resolution, aliases and summation.
• Roles will be built-in to Perl 6. Traits will not.
• If I wanted to implement roles in MT which CPAN module should I use? Class::Role, Class::Roles, Perl6::Roles? I'd assume the latter given the dates, docs and Perl6 namespace.
• If Perl6::Roles is the answer to the above, how up to date is it in terms of the current Perl6 implementation?

Your feedback would be appreciated. Thanks.

[stvn]

Would what MTOS is calling taggable, scorable qualify as a role or trait? I'm thinking yes, but the examples I've seen don't quite fall inline.

This "-able" thing is more aligned to how people use Java interfaces, which is only one way in which Roles/Traits can be used. Most of the time my Roles are named "HasDBICSchema" or something similar and simply provide, in this case, a DBIx::Class (commonly shortened to DBIC) Schema object. The reality is that Roles/Traits are still new, the smalltalk folks who invented traits are not seeing a lot of trait usage in the community (from my limited knowledge, so dont take that as 100% fact). The most usage is currently with Roles in the Moose community.

Roles seem to be a more simple and basic implementation of the traits idea.

Actually, its the opposite, roles can provide class attributes/slots which complicates them much more than traits which only allow methods. The deeper discussion of why this is so, is way out of the scope of this post, suffice to say that when I wrote Moose::Role I had a discussion with the original authors of the traits paper (whom I had already known from back when I had written Class::Trait), and when I asked them if they had figured out how to do slots in traits they said "No, but let us know if you figure it out". They have since written their own smalltalk version with attributes/slots and ended up having to add public/protected/private to Smalltalk and I got the impression they were generally unhappy with the result.

Traits includes more advanced features like overloaded operators, required method labels, conflict resolution, aliases and summation.

Actually, Moose::Role supports required methods, conflict resolution and aliasing. Summation and conflict detection are just how roles work, so I dont consider it a feature. Only Class::Trait supports overloaded operators, and the pain of having to write that is exactly why Moose::Role does not support overloaded operators.

Roles will be built-in to Perl 6. Traits will not.

Traits can really be viewed as a subset of Roles. Perl 6 doesnt support explicit method requirement, but simply doing method foo { ... } using the yadda-yadda-yadda operator will give you pretty much the same thing. As for conflict resolution, you can do that in a more manual way in Perl 6 then you can in Class::Trait or Moose::Role, but it is still generally possible.

If I wanted to implement roles in MT which CPAN module should I use? Class::Role, Class::Roles, Perl6::Roles? I'd assume the latter given the dates, docs and Perl6 namespace. If Perl6::Roles is the answer to the above, how up to date is it in terms of the current Perl6 implementation?

None of the above, all those modules should be considered toy implementations and are all woefully incomplete. The only complete and thoroughly tested Role implementation on the CPAN is Moose::Role.

[tima]

Thanks for the through reply. I have to admit that I feel more confused when I started though.

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

I'm interested in these sort of OOP concepts, but for the moment I'm just going to focus on how this sort of concept would apply to MT as it exists today and in the foreseeable future.

> This "-able" thing is more aligned to how people use Java interfaces, which is only one way in which Roles/Traits can be used.

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

> None one of the above, all those modules should be considered toy implementations and are all woefully incomplete. The only complete and thoroughly tested Role implementation on the CPAN is Moose::Role.

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 it.

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?

[stvn]

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.

• Class::Role is untouched for 5 years, written by Luke Palmer, who is a really good programmer but I know (because Luke told me) that this module was just an experiment to try out the ideas from the original paper.
• Class::Roles is also untouched for 5 years, this one written by chromatic and I suspect also an experiment to prove the usefulness of ideas in original Traits paper since chromatic was one of the people who brought the paper to the attention of the Perl6 group originally.
• Perl6::Role is untouched for 3 years, written mostly by dragonchild when he and I worked together, it was put together to help Tim Bunce in the prototyping of DBI version 2, as far as I know dragonchild has not used this module much and last I knew DBI v2 was using Moose.

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).

[dragonchild]

Perl6::Roles is not up-to-date vis-a-vis anything. I wrote it solely as a reference implementation for tbunce when he was looking at roles for DBI2. It was used as a reference implementation (along with Class::Trait, Class::Role, and all the others) when stvn wrote Moose::Role. That should be considered the most up-to-date implementation of anything OOP-related in Perl, both Perl5 and Perl6-in-Perl5.

[TGI]

If this is the case, please, please, please patch the POD for the module to clearly state it.

Another example of this is modules by TheDamian. Damian Conway has written some truly useful modules, but every time I consider using one of his works, I get a bit nervous and wonder "Is it safe to use this?". I refer to Categorized Damian Modules, but it isn't kept up to date. If he labeled each module in its documentation as to category, life would be much simpler.

I am thrilled when I am evaluating a list of CPAN modules and one of them says, "This module is deprecated. Use BLAH BLAH BLAH instead." It saves me the time of having to carefully consider it.

[dragonchild]

Sorry to be a bit harsh, but the '0.01' along with the last-upload date of 3 years ago should have given you a clue. Alternately, you could've just emailed me at [e-mail] and asked. I would've been delighted to respond and I do so with 24h (often much less).

As for updating the POD, I wrote it 3 years ago and promptly forgot about it. This is the first time anyone's ever looked at it for production use, so I am a bit surprised at the . . . vehemence. :-)

Please send me an email and I'll try to get to it next week.