in reply to Delegating to a role in Moose

Hi nysus, the intention of 
handles => 'Some::Role',

[download]
is that Some::Role simply acts as an interface i.e. it describes required methods but does not implement them.

There is an example of this in the Moose test suite: 

{
    package Foo::Bar;
    use Moose::Role;
 
    requires 'foo';
    requires 'bar';
 
    package Foo::Baz;
    use Moose;
 
    sub foo { 'Foo::Baz::FOO' }
    sub bar { 'Foo::Baz::BAR' }
    sub baz { 'Foo::Baz::BAZ' }
 
    package Foo::Thing;
    use Moose;
 
    has 'thing' => (
        is      => 'rw',
        isa     => 'Foo::Baz',
        handles => 'Foo::Bar',
    );
 
    package Foo::OtherThing;
    use Moose;
    use Moose::Util::TypeConstraints;
 
    has 'other_thing' => (
        is      => 'rw',
        isa     => 'Foo::Baz',
        handles => Moose::Util::TypeConstraints::find_type_constraint(
+'Foo::Bar'),
    );
}

[download]
Here you can see that the Foo::Bar role is used to specify delegation, but the actual methods are implemented in Foo::Baz.

Replies are listed 'Best First'.
Re^2: Delegating to a role in Moose
by nysus (Parson) on Jan 12, 2018 at 15:11 UTC

    Thanks, but I'm not sure I follow. The documentation doesn't mention using Moose::Util::TypeConstraints. What, exactly, does the code in the documentation do?</code>

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

[reply]
[d/l]
      Moose::Util::TypeConstraints isn't really important here and I should have edited it out of the snippet. The important thing to understand is 
      package Foo::Bar;
use Moose::Role;
 
requires 'foo';
requires 'bar';

      [download]
      i.e. required methods. This is how a role indicates that a class consuming it should have some extra behaviour that the role depends on. Taking this to an extreme you can even have a role that only has required method specifiers - this gives you something similar to the interface construct found in Java/C#/PHP.

      And this latter type of role is what is intended to be used when you specify a role to the 'handles' clause.

      Does that make sense?
[reply]
[d/l]

        In the documentation, it's made to look like you can extend or override methods provided by URI but from what I can tell it does nothing of the sort. Take this, for example, which emulates what is in the documentation:

        {
  package MyURIRole 0.000001;

  use Moose::Role;

  requires 'host';
  requires 'path';

  sub print_hi {
    my $s = shift;
    print "hi\n";
  }
}

{ 
  package MyURI 0.000001;

  use Carp;
  use Moose;
  use URI;

  has 'uri' => ( is => 'ro', isa => 'URI', handles => 'MyURIRole', );

}

#! /usr/bin/env perl
use MyURI;

use strict;
use warnings;

my $uri = MyURI->new( uri => URI->new('http://www.perl.com/the_path'))
+;
print $uri->host;
print "\n";
print $uri->path;
print "\n";
$uri->print_hi;

        [download]

        From the documentation's explanation, I would expect the $uri->print_hi to print out "hi". Instead, I get an error:

        Can't locate object method "print_hi" via package "URI::http" at inline delegation in MyURI for uri->print_hi (attribute declared in MyURI.pm at line 7) line 18.

        So I'm not sure why the documentation is suggesting that using a role name with handles is a good way to delegate when using another package like URI. What is to be gained from it? Am I missing something?

        $PM = "Perl Monk's";
        $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
        $nysus = $PM . ' ' . $MCF;
        Click here if you love Perl Monks

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom