Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday May 27, 2009
10:22 AM

Inheritance or Roles?

[ #39039 ]

Can anyone make an argument why I would ever want to use inheritance when I have roles available aside from modules which require you to inherit from them (e.g., DBIx::Class)? The more I use roles, the less I understand why anyone would want to use the inheritance model. Even with our admittedly complex requirements on our BBC team, inheritance just doesn't seem necessary.

Currently I'm rewriting a huge subsystem of "builders" where every single object uses the PIPs::API::Builder::Role::DoesBuilder role. Traditionally I would have made that a base class, but by making it a role, I gain the composition-time safety that inheritance can't give me. Counter-arguments welcome.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Don't be fooled, over use of roles is just as bad as over use of MI.

    I worry that perhaps your a little too blinded by the shiney right now. Now, it seems the BBC system your working on was full of MI, so in this case, yes it probably makes a lot of sense to go heavily with the roles. And DBIx::Class is also uses MI very heavily and the planned Mooseification of it involves converting much of that to roles. But there are some things that fit really nicely into the inheritance model and those things really

    • Thanks. I think that gives some great perspective on this. You had previously mentioned that overuse of roles was bad and I never asked you to follow up on your comment. I'll reread that paper (I read it years ago before I really was familiar with traits) and hopefully I'll have a better perspective now.

  • One of the papers that the Traits guys wrote called Applying Traits to the Smalltalk Collection Hierarchy [] is very relevant to this. It shows what is, in my opinion, a perfect example of where roles are best used and how they are superior to inheritance. The key thing to note is that they still retained a lot of inheritance where there was a true is-a relation, but they removed a lot of unnecessary inheritance that was really only there to achieve code reuse.

    - Stevan

  • Here's what I've been using:

    If you don't want instances of it, then it's not a class. In which case it's possibly (probably?) a role.

    So if you've got Foo and Bar and you're not sure if if you want "Bar does Foo" or "Bar isa Foo", then ask yourself if you want Foo->new(...) to work. If you do, then Foo is clearly a class and you want "Bar isa Foo". Otherwise Foo should be a role and you have "Bar does Foo".

    If you do want Foo->new(...) to work, I suppose you can get around having an isa rela
    • That's what I do as well, it just makes the most sense to me.

      Jonathan and Stevan's advice to think "is a dog an animal, does it walk?" is commonly sensible and easy to follow, but when I code, I don't always think that way. It's easier for me to look ahead and say "am I going to create an instance of this thing? Do I want to be able to?". It helped me refactor some things to roles and I haven't looked back on those. Of course, some people naturally think of the verb.

      It's nice to see how there's good advice

      • To be fair, advice on what to do is great, but advice on why to do it is more valuable. Stevan's input was great because he was offering concrete reasons. If those reasons are pertinent to your project, than they're worth taking into account. Otherwise, I'm still unsure that holding on to inheritance is particularly worthwhile. Most of the arguments in favor of it ultimately seem to revolve around syntactic issues (as does the role debate that I've had with chromatic and others).

        • That's a good point (that why is more valuable than what) but to me it was too general. Actually, a lot of why is too general to me. I don't have the programming depth perception some other really good programmers might have (Stevan, yourself, I could keep naming :) and so a rule of thumb can be useful for me to judge this situation on my own. I wouldn't say it never failed me but I'll say it's been relatively good to me.

          As for a situation I might want MI? How about...

          # this is probably a stupid example,

        • I think you need both parts. The How without the Why is, as you say, mechanical and and shallow, and prone to dogma; on the other hand, the Why without the How is too unconstrained and prone to lose touch with reality. I think Whys are not very useful in a vacuum; they must serve as justification for particular Hows in order to be worthwhile, much like Hows without a justifying Why are rarely useful (though not never – sometimes there is a meta-Why, namely, consensus).

  • I've found that a reasonable rule of thumb can be, if you can say "X is a Y" and it sounds sensible in relation to the real world entities, then inheritance is probably right. On the other hand, if it "X does Y" sounds much more natural then it's time to use a role. Of course, you can twist words to stick it into either, but I think we can probably agree that "Dog does Walk" sounds much natural than "Dog is Walker" and that "Dog is Animal" is more natural than "Dog does Animal".