On 11 August 2016 at 17:31, Niall Young <ni...@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
