On 3/27/15 9:01 AM, (Dagfinn Ilmari Mannsåker) wrote: > [email protected] (Dagfinn Ilmari > Mannsåker) writes: > >> Kent Fredric <[email protected]> >> writes: >> >>> On 27 March 2015 at 11:23, Diab Jerius <[email protected]> wrote: >>> >>>> I've translated some code using multiple inheritance to Moo, and am >>>> seeing some unexpected behavior, namely that attributes inherited >>>> from the second parent class are not properly initialized. >> […] >>> Given the code works as expected when you s/Moo/Moose/, both in value >>> initialization, and in explicitly passing arguments to the second-inherited >>> module at construction time, I would agree that you have in fact found a >>> bug in Moo. >>> >>> ( Unless of course Moo has some documentation about explicitly not >>> supporting multiple inheritance ) >> >> It doesn't. In fact, https://metacpan.org/pod/Moo#extends says «Multiple >> superclasses can be passed for multiple inheritance but please consider >> using L<roles|Moo::Role> instead», and there's no mention of the >> limitation in https://metacpan.org/pod/Moo#INCOMPATIBILITIES-WITH-MOOSE. >> >> However, fixing it breaks a few tests that assert that it _doesn't_ >> work: >> >> The tests were changed to expect the current buggy behaviour in this >> commit: >> >> commit f7813a5f2834a9dc03c7abdc2a9c4be940caa4e0 >> Author: Graham Knop <[email protected]> >> Date: 2014-04-15 00:43:12 -0400 >> >> fix multiple inheritance tests for expected behavior > > I've fixed the bug and reverted this commit on the multi-extends-default > branch <https://github.com/moose/Moo/commit/multi-extends-default>. >
This branch isn't going to be accepted as is, because there are a number of caveats that apply when using multiple inheritance with Moo that it doesn't handle. The easiest example when combining with Moose classes. Because of these caveats, the current test to validate the behavior is intentional. I have another branch (https://github.com/moose/Moo/tree/c3-attr) that is closer to what we'd want for this. It doesn't resolve the caveats, but at least makes it so the extra behavior has to be specifically requested. The docs about this are not adequate in either case. It should be documented what the issues are and why we've chosen the current implementation.
