develooper Front page | perl.perl6.users | Postings from January 2019

Re: Roles are fundamentally broken?

Thread Previous | Thread Next
Vadim Belman
January 30, 2019 01:40
Re: Roles are fundamentally broken?
Message ID:

The role must not be a class – that's true. Yet, have a look at my example with private methods. If accidentally two roles declare same private method – I either must reject using one of them or resolve the conflict manually... oh, wait, I have no idea of what is that private method is all about!

Another rare but not overall impossible pattern is when one would like to have a role method(s) be resolved with MRO. Something like:

    class Foo is A is B does R is C { ... }

where re-dispatching would be able to try resolving exactly in the specified order A -> B -> R -> C. Currently I see only two possible solutions:

- manual qualifiaction:
    self.?A::method; self.?B::method; self.?R::method; self.?C::method;

- Create an intermediate dummy class which would do R:

    class RClass does R { ... }
    class Foo is A is B is RClass is C { ... }

In the second case we would have do something with stubs in R because RClass would have to resolve them. And if this would require accessing private data on Foo then the latter would have to trust RClass:

    class Foo is A is B is RClass is C {
        trusts RClass;

Doesn't it look somewhat clumsy??

Oh, and after all, we have submethods! And know what? If you have a submethod on a Role everything is fine until same name submethod would be required by the consuming class. In this case the class developer must know explicitly that he has to call role's submethod and how he has to do it if the submethod is called externally (similarly to BUILD/TWEAK been called at the construction stage). Or the calling code must know about the existence of ^roles method and use it.

I don't want roles to become classes. But I wish they'd have more privileges than they do now. BTW, it is even possible to have both approaches within same paradigm by having two ways of consuming roles: either through MRO or by mixing in. A developer could choose which one would do better in a particular situation.

> I'm not an expert on OO programming, but my understanding of roles is that they make it possible to add some behaviors to a class (or to an object) while avoiding some of  the pitfalls of inheritance, especially of multiple inheritance. So, even though I know about punning, I would tend to argue that roles are not classes (if they were, well, why would we need to have roles?. In fact, I tend to think that they have been designed precisely not to be classes and not to exhibit inheritance features, in order to avoid the complex dependencies that sometimes arise with inheritance, especially multiple inheritance and, more generally, complex inheritance trees. So, in this view, roles should probably not need any MRO. If you need inheritance, then probably use full-fledged classes. If you don't need inheritance, then, possibly, roles may be better suited to what you need.
> To me, classes are meant for managing instances and roles for managing behaviors and code reuse.
> Having said all that, I like to be able to compose some role(s) into another role and I have done it a couple of times without encountering any problems, as far as I can tell (but these were probably relatively simple cases). I don't really see why this should be considered as an anti pattern, although I can certainly feel that we should probably not try to ask too much from roles, the aim after all is to have something simpler than a class.

Best regards,
Vadim Belman

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