Re^5: Sanity Check: Roles vs. Traits

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

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

Replies are listed 'Best First'.
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
Are there any guidelines on how to name roles? Nope, I tend to do a lot of "WithSomething" and "HasSomething", but only when it makes sense. I am really not a fan of the Java/C# interface practice of prepending an "I", so I would not suggest the same but with an "R" unless you like that practice. I think the "does" comes from the Perl6 keyword. But in Moose the keyword is "with", so that confuses things a bit. The reason we have "with" is that since that is really just a function, it would conflict with the "does" that is found in Moose::Object which is used to tell if something "does" a role `$object->does(My::Role)`. I would have preferred to have used "does" and be more Perl 6 compat, but I had to work around the Perl 5 limitations. FWIW, the "with" keyword comes from Scala. So, any good ideas on how to think or phrase the description of names for classes and roles? Not yet really, although I haven't given it a whole lot of thought. I am sort of waiting to see, as the group of people using roles grows, what patterns (actual patterns, not GoF patterns) begin to develop for usage and naming. At this point myself and nothingmuch have probably been using roles the longest (at least in Moose) and we each have our own approaches (see Forest and Bread::Board for examples of my usage and KiokuDB and Class::Workflow for examples by nothingmuch). I guess to not answer your question more clearly,.. there are no rules :) -stvn	[reply] [d/l]


Pathologically Eclectic Rubbish Lister
	PerlMonks