Re^3: Sanity Check: Roles vs. Traits

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

-stvn

Comment on Re^3: Sanity Check: Roles vs. Traits

Replies are listed 'Best First'.
Re^4: Sanity Check: Roles vs. Traits by jplindstrom (Monsignor) on Oct 31, 2008 at 14:18 UTC
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	[reply]
Re^5: Sanity Check: Roles vs. Traits by stvn (Monsignor) on Oct 31, 2008 at 16:10 UTC
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. 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). 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. -stvn	[reply]
Re^6: Sanity Check: Roles vs. Traits by jplindstrom (Monsignor) on Oct 31, 2008 at 17:07 UTC
perhaps your already existing role was incorrectly named. That's probably true. I think maybe the role was applied at the wrong level. It should have been applied to the new base class I was trying to name. I've been meaning to ask for a while now: Are there any guidelines on how to name roles? Like for inheritance there's the "is a", e.g. Broadcast is a PublicationEvent. The PublicationEvent does HaveIdentifiers. I think the "does" comes from the Perl6 keyword. But in Moose the keyword is "with", so that confuses things a bit. So, any good ideas on how to think or phrase the description of names for classes and roles?	[reply]
Re^7: Sanity Check: Roles vs. Traits by stvn (Monsignor) on Oct 31, 2008 at 18:39 UTC


P is for Practical
	PerlMonks