Skip Menu |

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 79572
Status: open
Priority: 0/
Queue: Moose

People
Owner: Nobody in particular
Requestors: rmesser [...] intellisurvey.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 2.0402
  • 2.0403
  • 2.0500-TRIAL
  • 2.0501-TRIAL
  • 2.0502-TRIAL
  • 2.0600
  • 2.0601
  • 2.0602
  • 2.0603
Fixed in: (no value)



Subject: subclass attribute overrides kill method modifiers
Adding an override to an attribute seems to kill method modifiers supplied in the superclass. Here's an example: package Foo { use Moose; has 'foo' => ( is => 'rw', isa => 'Str', ); before 'foo' => sub { my $self = shift; print "before foo for a " . ref($self) . "\n"; }; }; package FooChild { use Moose; extends 'Foo'; has '+foo' => ( default => 49 ); }; my $f = Foo->new(); $f->foo(); my $fc = FooChild->new(); $fc->foo(10); This prints just "before foo for a Foo" -- there is no call to the "before" method for the FooChild. But if you comment out the "has '+foo'" line, the method modifier runs just fine for FooChild. This problem is also described here: http://stackoverflow.com/questions/12363971/perl-moose-triggers-in-subclasses-disrupt-method-modifiers I've tried this with 2.0402 and 2.0603, and see the same problem. Both were tested with Perl 5.14.2.
I'm not sure this is fixable unless we have inherited attributes look at their parent classes for method modifiers and explicitly reapply them. The problem is that inherited attributes go through the same "add an attribute" code that non-inherited ones do. That code path does a bunch of things, including making a new meta-attr object and installing the accessors it generates. In this case the inherited attribute generates a new set of accessors. Note that this is required because the attribute could be overriding the accessor generation itself (changing from "ro" to "rw", for example). I'm inclined to say that this isn't a bug, but we could add some docs at least.
Subject: Re: [rt.cpan.org #79572] subclass attribute overrides kill method modifiers
Date: Mon, 12 Sep 2016 09:14:24 -0700
To: bug-Moose [...] rt.cpan.org
From: Robert Messer <rmesser [...] intellisurvey.com>
If this is hard to fix I could see it falling into a “not worth fixing” category. To a programmer who simply adds a default to an attribute found a parent class (or role), it certainly seems like a bug, in that method modifiers are unexpectedly gone for the subclass/role consumer. But it’s been 4 years since the issue was reported, and it isn’t particularly hard to work around it, so I can understand that changing the current behavior isn’t much of a priority, and handling it via docs is reasonable. Probably just a short note in the section that talks about modifying attributes with the “+” syntax would be helpful. Show quoted text
> On Sep 11, 2016, at 9:56 AM, Dave Rolsky via RT <bug-Moose@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=79572 > > > I'm not sure this is fixable unless we have inherited attributes look at their parent classes for method modifiers and explicitly reapply them. > > The problem is that inherited attributes go through the same "add an attribute" code that non-inherited ones do. That code path does a bunch of things, including making a new meta-attr object and installing the accessors it generates. > > In this case the inherited attribute generates a new set of accessors. Note that this is required because the attribute could be overriding the accessor generation itself (changing from "ro" to "rw", for example). > > I'm inclined to say that this isn't a bug, but we could add some docs at least.
On 2016-09-12 09:14:33, rmesser wrote: Show quoted text
> If this is hard to fix I could see it falling into a “not worth > fixing” category. To a programmer who simply adds a default to an > attribute found a parent class (or role), it certainly seems like a > bug, in that method modifiers are unexpectedly gone for the > subclass/role consumer. But it’s been 4 years since the issue was > reported, and it isn’t particularly hard to work around it, so I can > understand that changing the current behavior isn’t much of a > priority, and handling it via docs is reasonable. Probably just a > short note in the section that talks about modifying attributes with > the “+” syntax would be helpful.
This is partially addressed in https://github.com/moose/Moose/pull/130, to be in 2.1806.