----- 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.
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?
"alias" and "excludes" are simple, clean ways of dealing with role composition
issues that arise. They are a code smell. A code smell doesn't mean that
there's defintiely a bug; it means that there may be an issue and it's worth
looking at further. When another team at work writes a role that's useful in my
code, I would like to simply be able to use that role and not jump through
hoops because other developers have decided that alias and exclude are always
bad and therefore I can't have it.
Rather than showing me hacks to work around the plans to deprecate these
features, can someone at least make a strong argument why these features are so
bad that they need to be eliminated? Preferably with code examples? Heck, even
if the explanation is "these features are valuable but caused many bugs inside
Moose", I could at least see a rationale for this removal. Instead, this sounds
dangerously close to the old problem of "we need a word processor that only has
the 10% of features that people actually use", but ignores the fact that
different people use different subsets of behavior.
Regards,
Ovid
