----- Original Message ----
> From: Jon Lang <[email protected]>
> 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
