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
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Roles and Inheritance (Score:2)
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).
Reply to This
Re: (Score:1)
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.