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

Re: Why to use Moose roles ever?

Thread Previous | Thread Next
From:
Niall Young
Date:
August 11, 2016 05:31
Subject:
Re: Why to use Moose roles ever?
Message ID:
alpine.OSX.2.20.1608111507300.88165@niall.local
On Thu, 11 Aug 2016, Kent Fredric wrote:

> On 11 August 2016 at 16:36, Niall Young <niall@iinet.net.au> wrote:
>> On Thu, 11 Aug 2016, Kent Fredric wrote:
>>
>>> On 11 August 2016 at 15:43, Niall Young <niall@iinet.net.au> 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.
>
> OP:
>> Moose roles have some limitations, such as inability to override a
>> method in a class which "with"es the role.
>
> Overriding a method in a parent class that composes a role is
> identical in practice
> to overriding a method in a composed role.

I'm not trying to be pedantic, but overriding a method != utilising a method modifier to achieve a similar/same outcome.  The syntax used to achieve that outcome is important, to me it's actually more important than having the capability to achieve approximately the same outcome, if that means utilising a workaround and/or inconsistent syntax (cognitive overhead, keeping in mind all of the constraints/quirks etc.).

> "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.

>> 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.
>
> But this is good, really, you shouldn't be "trying to find a use for
> it", that's sort of coding-by-patterns and it never ends well.

Oh you misunderstand, I have many uses for them e.g. all of the benefits of Traits and composing behaviours (safely and predictably via commutative and associative safety) over deep or multiple inheritance.  But every single attempt to utilise them for that purpose has left me disappointed, and I've been unable to justify the cost that they introduce.

> Because "with" not only indicates "Please compose X" , but advertises
> "I conform to interface X"

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

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.

--
Niall Young
niall@iinet.net.au

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