----- Original Message ---- > From: Jon Lang <datawea...@gmail.com>
> Right. But as they were originally conceived, they were interfaces > that could also handle code reuse, rather than units of code reuse > that could also be used as interfaces. From this perspective, it > makes perfect sense that a role's methods can be overridden as easily > as they are. As originally conceived in Perl 6 or in the original traits papers? In the original research, the purpose of roles was to allow the decoupling of responsibility and behavior (code reuse) found in inheritance-based OO systems. Traits (roles) took over code reuse. > But you make a good point: there are some (a few? most?) programmers > who are going to want to use roles primarily for code reuse, and who > will want it to be a little more difficult to override the code > provided by a role (e.g., requiring the use of supersede and perhaps > augment in order to replace the definition with a new one). Just to give people some real data to play with (our system may not be representative), here's some sample source code and some imformation about our use of roles in the BBC. package PIPs::ResultSource::Series; use Moose; extends 'PIPs::ResultSourceBase::BrandSeries'; with qw( PIPs::ResultSource::Role::DoesParentChildRelationships PIPs::ResultSource::Role::DoesTags PIPs::ResultSource::Role::DoesContentObject PIPs::ResultSource::Role::DoesInspector PIPs::ResultSource::Role::DoesRelatedLinks PIPs::ResultSource::Role::DoesIdentifiers PIPs::ResultSource::Role::DoesChangeEvents ); (The astute reader will not that the base class is awful, but it's been a long, hard slog to get this far). Most of our classes which implement roles have similar preambles, but with different behaviors listed. Other points of interest. Only 11 of 114 classes which implement roles exclude any methods (none use method aliasing) and we currently have 40 roles implemented. Only three classes provide methods which override role's methods, but in the few cases they do, we explicitly exclude the methods from the role to make it clear that we need to do this. We had more overriding of role's methods, but continual refactoring has pushed those into roles. So we're very, very heavily on the "use roles for shared behavior" side. The relative paucity of overridden role methods suggests to me that (for our code), the annoyance of having to be explicit for overridding a role's methods easily offset by how hard it's been to debug this issue. That being said, the pain in debugging might have been a side effect of the fast transformation from a complex inheritance hierarchy to a roles-based system. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6