![]() |
|
Perl: the Markov chain saw | |
PerlMonks |
Re^4: Sanity Check: Roles vs. Traitsby jplindstrom (Monsignor) |
on Oct 31, 2008 at 14:18 UTC ( #720704=note: print w/replies, xml ) | Need Help?? |
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
In Section
Seekers of Perl Wisdom
|
|