Chris - many thanks for the clear explanation - that all makes sense.

However (unless I'm missing something) it does seem reasonable that if an
object provides access to another object's accessor via a delegation method
then it should be also be able to provide access to the same accessor during
initialisation (or there should at least be some generic means of doing so).

Ah - I've just seen Stevan's email :) I may well have a go at a MooseX
module when I can clear some time - any suggestions for suitable names or
where/how this should fit in would be very welcome -
MooseX::DelegateInitHandles ?

  ####

  package MyClass;
  use Moose;
  use MooseX::DelegateInitHandles;

  # provides optional class attribute 'delegate_init_handles'
  # which, if set, passes on init params according
  # to appropriate accessors mentioned in "handles"

  has 'result' => (
      is        => 'rw',
      isa       => 'MyClass::Result',
      default   => sub { MyClass::Result->new() },
      handles   => [qw( query match score )],
      delegate_init_handles => 1,
        # bool turns on all handles
        # or specify which handles to use with array ref
        #   [qw( query match )]
  );

  ####

  package MyClass::Result;
  use Moose;

  with 'Role::HasComparisonResult';

  ####

  package Role::HasComparisonResult;
  use Moose::Role;

  has 'query' => ( is => 'rw' );
  has 'match' => ( is => 'rw' );


  Without MooseX::DelegateInitHandles

    $c = MyClass->new( query => 'foo' );
    $c->query()       # undef
    $c->query( 10 );  # 10

  With MooseX::DelegateInitHandles

    $c = MyClass->new( query => 'foo' );
    $c->query()       # 10



Cheers,

Ian

-- 
Dr Ian Sillitoe
CATH Team -- http://cathdb.info

"Advice is what we ask for when we already know
the answer but wish we didn't" -- Erica Jong

Reply via email to