Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Briefly, the difference most people make between roles and inheritance is that inheritance should be used for class responsibility and roles should be used for cross-cutting concerns. For example, if you have a Dog class, it should inherit from Mammal rather that have Mammal being a role, but since many unrelated classes might need serialization, a role makes more sense.

    At work, I still use inheritance with roles because I tend to be a bit more cautious at work than I do in my posts, but I do have one critical (and fairly large) subsection I wrote where everything was composed with roles and no inheritance was provided (even in one case where inheritance seemed the right way to go). As a result, I had some lovely composition-time safety that I could not have gotten via inheritance.

    While I have read papers explaining when to use each, I've yet to see the downside of a "role only" OO implementation (if Eiffel was single-inheritance, that would be a better argument for mixing classes and roles because its inheritance is much safer than Perl's).

    • Ok, what you're saying fits my experience as well. It seems like "role only" OO should be able to work, but there also seems to be no compelling reason to make everything into roles.