--- On Mon, 12/10/09, Jesse Luehrs <[email protected]> wrote:
> From: Jesse Luehrs <[email protected]>
> Yeah, something like this would work:
>
> package Thing;
> use Moose;
> has robot_arm => (
> is => 'ro',
> isa => 'RobotArm',
> default => sub {
> my $self = shift;
> return RobotArm->new(to_draw => $self);
> },
> handles => { draw_with_arm => 'draw' },
> );
So instead of this:
package Thing;
use Moose;
with (
DoesRobot => { excludes => 'draw', aliases => { draw => 'draw_with_arm' } },
'DoesDrawable'
);
You recommend this:
package Thing;
use Moose;
has robot_arm => (
is => 'ro',
isa => 'RobotArm',
default => sub { RobotArm->new({ to_draw => shift }) },
handles => { draw_with_arm => 'draw' },
);
This is interesting in a couple of ways. Aside from the fact that we have more
scaffolding code we have to write, we no longer get our composition-time safety
from 'requires' which roles provide. With delegation, if $self doesn't provide
the methods you need, you get your failures at runtime instead of composition
time. This is a problem when delegation requires bi-directional in the sending
and receiving objects.
Mind you, I'm not saying you're wrong. I think this technique is fine if you
already have a RobotArm class handling this particular case. I'm just toying
more and more with the idea of assembling classes out of role-based components
(something I'm not pushing for production, of course). Separation of concerns
is important, but I want to hear more concrete wins of delegation over role
composition :)
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
