in reply to moose role that uses a class that does the 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.

  • Comment on Re: moose role that uses a class that does the role

Replies are listed 'Best First'.
Re^2: moose role that uses a class that does the role
by mjbetts (Initiate) on Jun 28, 2012 at 14:48 UTC
    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]
[reply]
[d/l]
[select]

      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.

[reply]
[d/l]
[select]

      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.

[reply]

In Section Seekers of Perl Wisdom