develooper Front page | perl.moose | Postings from August 2016

Re: Why to use Moose roles ever?

Thread Previous | Thread Next
Niall Young
August 11, 2016 04:37
Re: Why to use Moose roles ever?
Message ID:
On Thu, 11 Aug 2016, Kent Fredric wrote:

> On 11 August 2016 at 15:43, Niall Young <> wrote:
>> Not sure how your example applies here Karen, there is no foo() declared in
>> MyClass only a foo method modifier, and MyRole's foo() doesn't appear to be
>> executed from your output?
> In the example she gave, the point was not to call MyRole's foo, only
> to replace it. ( Because Roles prohibit replacement by default, its a
> conflict that must be manually resolved )

The OP's goal was to override MyClass's foo, not MyRole's foo.

> If one wants to call MyRole::foo in the new MyClass::foo, this is done:
>    around foo => sub {
>       my ( $orig, $self, @args );
>       return join q[, ],  'I came from the class', $self->$orig( @args );

It seems cumbersome, and makes Classes aware of and dependent on the existence of Role(s).

Like the OP I struggled to come up with a good way to take advantage of Roles, as nice as they are in principle there are some fundamental constraints which make applying them (and enjoying their inherent benefits, or start approaching the benefits of Traits) problematic.

Moose cleans up Classes tremendously, which by itself is a pretty huge win (not to mention access to the MOP at runtime etc.) but Roles .. like the OP I'm still struggling to find a use-case which lives up to their potential.  I really, really want to use them, but they come with their own issues, or costs which seem to negate or outweigh their benefits.  That's not a criticism btw, just an observation.

Niall Young

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About