Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^4: Sanity Check: Roles vs. Traits

by jplindstrom (Monsignor)
on Oct 31, 2008 at 14:18 UTC ( [id://720704]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Sanity Check: Roles vs. Traits
in thread Sanity Check: Roles vs. Traits

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

Replies are listed 'Best First'.
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.

    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.

    -stvn
      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?

        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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://720704]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2024-03-28 22:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found