Hi, 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, Laurent. Le mar. 29 janv. 2019 à 16:50, Vadim Belman <vr...@lflat.org> a écrit : > > > > On Jan 29, 2019, at 3:43 AM, Simon Proctor <simon.proc...@gmail.com> > wrote: > > > > I think part of the issue is that fundamentally Roles are intended to be > a way of doing non inheritance based classes. So composing Roles from other > Roles is an anti pattern. > > But why? As I stated in my previous reply: isn't it constraining for the > purpose of constraining? To me Perl was always TMTOWTDI in first place. The > current approach to roles contradicts this principle. > > Best regards, > Vadim Belman >
