Re: Moo, multiple-inheritance, unexpectedly uninitialized attributes

[Kent Fredric]

On 27 March 2015 at 11:23, Diab Jerius <dje...@cfa.harvard.edu> wrote:

$ perl tst2
b1
Use of uninitialized value in say at tst2 line 30.

In tst2, if I explicitly initialize the attribute from the second class:

  my $q = C11->new( b2 => 'BBB' );

It is still output as uninitialized.

Would someone please point out what I'm missing?

Thanks,

Diab

Seems if you make your accessors lazy, then it works.

Which implies something is weird in construction.

--

Kent

KENTNL - https://metacpan.org/author/KENTNL

[Jim Bacon]

I would think that you would want to get rid of the multiple inheritance if possible by making one them a role unless refactoring to that extent is not possible.

Jim

[Diab Jerius]

One step at a time...

[Kent Fredric]

On 27 March 2015 at 11:23, Diab Jerius <dje...@cfa.harvard.edu> 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.

I've attached simplified versions of the pre- and post- Moo code.  The
pre-Moo code generates this:

$ perl tst1
b1
b2

The Moo code outputs this:

$ perl tst2
b1
Use of uninitialized value in say at tst2 line 30.

In tst2, if I explicitly initialize the attribute from the second class:

  my $q = C11->new( b2 => 'BBB' );

It is still output as uninitialized.

Would someone please point out what I'm missing?

Thanks,

Diab

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 )

[Kent Fredric]

On 27 March 2015 at 18:30, Kent Fredric <kentf...@gmail.com> wrote:

I would agree that you have in fact found a bug in Moo.

Oh indeed, its even been reported: https://rt.cpan.org/Ticket/Display.html?id=99225

[(Dagfinn Ilmari Mannsåker)]

Kent Fredric <kentf...@gmail.com>
writes:

> On 27 March 2015 at 11:23, Diab Jerius <dje...@cfa.harvard.edu> 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:

# Failed test 'can't extend attribute from second parent'
# at t/has-plus.t line 73.
# undef
# doesn't match '(?^:no d attribute already exists)'
[…]
# Failed test 'constructor doesn't populate right parent attribute'
# at t/moo-c3.t line 34.
# got: '3'
# expected: undef

The tests were changed to expect the current buggy behaviour in this
commit:

commit f7813a5f2834a9dc03c7abdc2a9c4be940caa4e0
Author: Graham Knop <ha...@haarg.org>
Date: 2014-04-15 00:43:12 -0400

fix multiple inheritance tests for expected behavior


--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen

[(Dagfinn Ilmari Mannsåker)]

ilm...@ilmari.org (Dagfinn Ilmari

Mannsåker) writes:

> Kent Fredric <kentf...@gmail.com>
> writes:
>
>> On 27 March 2015 at 11:23, Diab Jerius <dje...@cfa.harvard.edu> 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 <ha...@haarg.org>
> 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>.


--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of." -- Skud's Meta-Law

[Diab Jerius]

Thanks

[Graham Knop]

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.