I would guess that you really want to use requires in your role to require certain functionality of the consumer of your role (in this case Greeting) possibly combined with normal inheritance. For example:

package Hello;

use Moose::Role;
use namespace::autoclean;

# Insist that someone who "with"s us, has a greet method
requires "greet";


sub hello_world {
    my $self = shift;
    $self->greet("hello world\n");
}

1;
[download]

Greeting:

package Greeting;

use Moose;
use namespace::autoclean;

with 'Hello';

sub greet {
    my ($self, @stuff) = @_;
    print @stuff;
}

__PACKAGE__->meta->make_immutable;
1;
[download]

Greeting2:

package Greeting2;

use Moose;
use namespace::autoclean;

with 'Hello';

sub greet {
    my ($self, @stuff) = @_;
    print map uc($_), @stuff;
}

__PACKAGE__->meta->make_immutable;
1;
[download]

Greeting3 (uses the greet from Greeting):

package Greeting3;

use Moose;
use namespace::autoclean;

extends 'Greeting';
# already "with" Hello

__PACKAGE__->meta->make_immutable;
1;
[download]

Now your test script produces:

Greeting=HASH(0x2b411f8)        does Hello
hello world

Greeting2=HASH(0x1a541f8)       does Hello
HELLO WORLD

Greeting3=HASH(0x15c01f8)       does Hello
hello world
[download]

Update: Added script output. Also, I second tospo's suggestion to move all of the common functionality to the Hello role

I'm surprised the universe didn't implode... :-)

Never tried this but, yeah, I guess it's reasonable to assume that the short-circuit is the problem here. What is the use case for something like this? It should be possible to move common functionality out of Greeting and into the Hello role so that the Hello role implements all of that and Greeting just consumes it. After all, that's the ponit of roles.

Thanks for your reply. My use case is that I have classes that are basically lists of other objects. Within a role I have a few methods that can produce new instances of these classes. Something like the code below (the real code is a nightmare, which may be part of the problem...). There is probably a way to do this along the lines that you suggest, but I'm having a hard time figuring out how...

package Cluster;

use strict;
use warnings;
use Moose::Role;
use namespace::autoclean;
use Group;

sub cluster {
    my($self) = @_;

    # cluster the members of this group, producing several
    # sub groups whose members may be clustered further
    my $sub_group1 = Group->new();
    my $sub_group2 = Group->new();

    return [$sub_group1, $sub_group2];
}

1;
[download]

package Group;

use strict;
use warnings;
use Moose;
use namespace::autoclean;

with 'Cluster';

__PACKAGE__->meta->make_immutable;

1;
[download]

What if you made the role parametric in one way or another? The role could require the presence of a method (created_class_name()) which Group could provide and, in this case, returns only the string 'Group'. That would decouple the class and the role, at least in the code you've shown here.

Another approach is to use MooseX::Role::Parameterized and pass in the class name when you compose the role.

---

Improve your skills with Modern Perl: the free book.

I guess this sort of recursion won't work as a role. A role can not depend on one of the classes it is consumed by, it should be independent and only define functionality that can be consumed by various classes. Cleary, this separation is not possible here.

So, why a role at all? Are there really other classes that are very different from Group that can also cluster? If they are similar to the Group class then I think this would better be designed using inheritance, where Group implements the "cluster" method and then you may have sub-classes of Group (or come up with a new parent that Group is a child of too) which modify the behaviour of Group.

In Hello.pm, you can change use Greeting to require Greeting, and then all should be well.

Another fix would be to swap the two use lines in test.pl

The reason this problem occurs is as follows.

1. perl loads test.pl; it encounters use Greeting2.
2. perl loads and compiles Greeting2.pm with no problems. Then with 'Hello' gets executed.
3. Moose::with loads Hello.pm.

Now we've got to look at what happens during the compilation stage of Hello.pm. This is when use and BEGIN things are executed, but not other stuff. In particular, no subs have been defined within the Hello package yet!

4. perl encounters use Greeting.
5. perl loads and compiles Greeting.pm with no problems. Then with 'Hello' gets executed.
6. Moose says to itself, "the Hello role has already been loaded, I don't need to load it again".
7. Moose copies all methods defined in the Hello role into the Greeting class. But, as we established before stage 4, there are not any subs in Hello yet!

... and the rest of the load process is uninteresting.

Changing use Greeting to require Greeting in Hello.pm fixes things because it forces that step 4 to happen a little later, after Hello has been fully compiled.

See also: leaky abstraction.

Update: as a general principle, for "cross-loading" between classes and roles within the same "clan" (i.e. collection of modules written for a particular project), I'd recommend loading them at run time instead of compile time. That means load them with require rather than use; or load them with Class::Load (which is one of Moose's dependencies, so you've already got it!); or rely on the fact that with and extends automatically load their argument. This advice only applies to classes and roles within the clan; not to pragmata, exporters, third-party classes, etc.