On Fri, Mar 29, 2013 at 05:34:50AM -0700, Ovid wrote:
> ----- Original Message -----
>
> > From: Lars Balker <l...@balker.dk>
> >
> > As Jesse's earlier example showed, instead of excluding and aliasing,
> > just refer to the methods directly within the roles:
> >
> > use v5.10.0;
> > { package R::Programmer; use Moose::Role; sub pay_rate {12} }
> > { package R::Clerk; use Moose::Role; sub pay_rate {10} }
> > { package R::Employee; use Moose;
> > with 'R::Programmer';
> > with 'R::Clerk';
> > has [qw/programming_hours drudgery/] => ( is => 'ro' );
> > sub paycheck {
> > my $self = shift;
> > return $self->R::Programmer::pay_rate * $self->programming_hours
> > + $self->R::Clerk::pay_rate * $self->drudgery;
> > }
> > }
> > my $employee = R::Employee->new(
> > programming_hours => 15,
> > drudgery => 25,
> > );
> > say $employee->paycheck;
>
>
> With 'R::Programmer' and 'R::Clerk' composed on separate lines, you no
> longer get compositional safety and roles become little more than
> glorified mixins. These were problems that roles/traits were designed
> to fix. This is not an improvement.
There's no need to actually compose them separately, things work just
fine if you compose them on the same line.
> And I should not have to hardcode the class names into my method
> names. That's a hack that we sometimes fall back on to work around MI
> limitations when you're trying to call an otherwise unreachable method
> and now it's bubbling up into roles?
How is this meaningfully different? You're already hardcoding the role
names at the point where you consume them.
-doy
