Re^2: Sanity Check: Roles vs. Traits

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

[jplindstrom]

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.

So would you say it's better to try to use Roles exclusively, or a mix of inheritance and roles?

Recently I've tried to not use inheritance for implementation convenience, only when it's semantically "correct", i.e. when A really is-a B.

In my experience, using both inheritance and roles makes for a more complicated (and possibly confusing) code structure. You need to remember which things are roles a and which things are base classes. At one point, it turned out we needed to create a base class to extract common configuration, and the proper name for that base class would be the same name as an existing role.

I think I've just recently passed the phase where I consider Roles to be "cool". You know, like when newbies encounter the GoF book and suddenly everything looks like a pattern.

So while Roles are a great tool to use, I think we (as a community) need more experience using them, more guides on when and how to use them, and how to name roles (vs naming classes).

/J

[stvn]

I couldn't agree more, all too often people reach for roles cause they are shiny and then try to use them everywhere. I stress in my OSCON talk that roles are not equal to classes. That the most common usage I have found is as a replacement for something in which I would have previously used multiple inheritance. But that they should never be thought of as a replacement for inheritance a never be used in a case when classes make perfect sense.

In my experience, using both inheritance and roles makes for a more complicated (and possibly confusing) code structure.

I found that too, but now I tend to do one of two things in order to keep the role/class distinction clearer.

1. My role is an abstract interface so I have My::Thing and then several concrete classes which use the role are in My::Thing::Something (see Forest::Tree::Indexer, Forest::Tree::Reader, Forest::Tree::Writer for an example of this approach).
2. My roles are common functionality for a given set of classes (My::App::*) so I create a Roles sub-namespace (My::App::Roles::*) and stuff all these roles in there.

At one point, it turned out we needed to create a base class to extract common configuration, and the proper name for that base class would be the same name as an existing role.

Honestly, that sounds like a perfect use case for a role (or several roles), perhaps your already existing role was incorrectly named.