On Thu, 11 Aug 2016, Kent Fredric wrote:
On 11 August 2016 at 16:36, Niall Young <ni...@iinet.net.au> wrote:
On Thu, 11 Aug 2016, Kent Fredric wrote:
On 11 August 2016 at 15:43, Niall Young <ni...@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
ni...@iinet.net.au
