On Thu, 2003-12-11 at 18:15, Jonathan Lang wrote: > Based on the source material pointed to as your inspiration for roles, I'm > a little confused as to how roles and classes could be unified. From what > I read in the source material, a key point of a role (well, they weren't > actually calling it a 'role' there, but I'm not recalling the term that > they did use) is that you get to bypass the "diamond inheritence" problem > by relegating member variables to classes, so that when you use multiple > roles to construct a class you don't have to worry about deciding which > version of the variable to access in any given method.
That's true, but that's incidental to the point of roles. It falls out from the important thing about roles. > Without that restraint, exactly how does a role differ from a multiple inheritence > model? Roles are a *more general* means of polymorphism and code reuse than inheritance. Inheritance is a *means* of performing a role, but it's not the only one. What's important about a role is that it marks the most important question (at least for polymorphic purposes): does this thing do what I'm about to ask it to do? It can do that role because of inheritance, but it can also do it because you've reimplemented all of the necessary methods, because you've aggregated an object that perform that role, or because you're delegating to an object that performs the role. If the only tool in your toolbox is isa(), you must either fake up some inheritance scheme or go without the three other allomorphic techniques. That's a shame. Roles exist because you can't fit all of the useful behavior in a system into a rigid class hierarchy -- some bits apply across classes -- without creating a mess. Again, inheritance is only one way a class can fulfill a role. It's not the only way and it's not necessarily the best way. See Class::Roles on the CPAN. -- c
