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

Re: Why to use Moose roles ever?

Thread Previous | Thread Next
From:
Kent Fredric
Date:
August 11, 2016 08:21
Subject:
Re: Why to use Moose roles ever?
Message ID:
CAATnKFATxrW-kL-WovK-OSE35zWQY3aAiaUudKPj-n4Mz2YjhQ@mail.gmail.com
On 11 August 2016 at 17:31, Niall Young <niall@iinet.net.au> wrote:
>> "around" retrieves MyClass::foo ( which was MyRole::foo ) and
>> wraps/overrides it.
>
>
> Wraps yes, override ... not in my book, but I appreciate where you're coming
> from.

Right. You should be able to use normal override mechanics, just
wrapping is more practical for some concerns.

If you can give examples of a case where you "can't override" that
seems like it would be helpful.

> Can you point to "interface X"?  In my (admittedly limited) experiments with
> Moose::Role an "interface" doesn't exist, conceptually or practically.  I
> was hoping to implement Interface roles, and have Implementation roles which
> provide behaviours (my final trade-off experiment was to explore it via
> inner-augment), and have them consumed by Classes in a sane and safe way,
> but I couldn't find one e.g. not being able to have an Implementation role
> depend on an Interface role, and have those indirect Interface dependencies
> automatically consumed by a Class

Roles are basically usable as 2 things. But yes, there's no formal
"interface", simply "roles that require methods or provide them".

Thus, a role enforces the method is "there" in some way, either by
providing it itself, or using the "requires" technique.

The name of the role is the name of the interface it provides, because
every thing that consume a role can be checked via "does"

Some roles may opt to provide no subs of their own, and are merely a
collection of "requires" statements that require the class that
composes them to define it.

So, by consuming a role of either type, you "claim" that you support
the API as documented in that role. ( But the implementation as to how
that claim is satisfied can vary )

> But I think we're straying far from the OP - I don't think we've seen a
> concrete example that helps him.  I suspect he's arrived where many of us
> have, where no amount of Moose design-rationale or workarounds seem
> appropriate in solving the types of problems that we're trying to solve.

Sure, and there are problems here, if you use too many roles you'll
hurt yourself, if you use too much inheritance you'll hurt yourself.

Some work flows make sense, others don't.

But as I mentioned earlier, I'm much more leaning towards attribute
based composition where possible with method delegation. Deep
hierarchies will make your life hard regardless of how you do it.

So the best choice is not to.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About