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.
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.
In reply to Re^5: Sanity Check: Roles vs. Traits
by stvn
in thread Sanity Check: Roles vs. Traits
by tima
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |