Bug #89272 for Moo: Error when Role/Class attributes collide

Sun Oct 06 03:05:11 2013 calid1984 [...] gmail.com - Ticket created

Subject:	Error when Role/Class attributes collide
Date:	Sun, 6 Oct 2013 02:04:57 -0500
To:	bug-Moo [...] rt.cpan.org
From:	Dylan Cali <calid1984 [...] gmail.com>

Moo: package FooRole; use Moo::Role; has quux => ( is => 'ro', ); 1; package Bar; use Moo; with q(FooRole); has quux => ( is => 'ro', ); __PACKAGE__->meta->make_immutable(); package main; my $b = Bar->new(); # error: You cannot overwrite a locally defined method (quux) with a reader at /home/calid/perl5/lib/perl5/Method/Generate/Accessor.pm line 37. Moose: package FooRole; use Moose::Role; has quux => ( is => 'ro', ); 1; package Bar; use Moose; with q(FooRole); has quux => ( is => 'ro', ); __PACKAGE__->meta->make_immutable(); package main; my $b = Bar->new(); # noerror Perl version: 5.18.1 Moo version: 1.003001

Sun Jan 18 08:34:06 2015 MITHALDU [...] cpan.org - Correspondence added

Since nobody else has answered this yet: More details are needed. It's so far a little bit unclear why you need this, what you wish to achieve, and as an extension of that, exactly what kind of implementation would fulfill your needs.

Sun Jan 18 08:34:08 2015 The RT System itself - Status changed from 'new' to 'open'

Sun Jan 18 10:04:15 2015 calid1984 [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #89272] Error when Role/Class attributes collide
Date:	Sun, 18 Jan 2015 09:04:03 -0600
To:	bug-Moo [...] rt.cpan.org
From:	Dylan Cali <calid1984 [...] gmail.com>

On Sun, Jan 18, 2015 at 7:34 AM, Christian Walde via RT <bug-Moo@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=89272 > > > Since nobody else has answered this yet: > > More details are needed. It's so far a little bit unclear why you need this, what you wish to achieve, and as an extension of that, exactly what kind of implementation would fulfill your needs.

Well, shouldn't the consuming class of a Role be allowed to override an attribute without issue (and in fact is able to do so in Moose)?

Sun May 22 18:14:07 2016 haarg [...] haarg.org - Correspondence added

This is mainly an ordering issue. subs are created at compile time, so they exist before a role is composed. Attributes are created at runtime though, so they need to be defined before composing the role to override it. Tracking the origin of attributes to allow them to be overridden is not something we're interested in doing in Moo, especially since it would essentially require us to be able to remove an attribute, which isn't something we support either. The solution here is to either define the attribute before composing the role, or use `has '+attr' => (...);` to modify the existing attribute. Marking as rejected.

Sun May 22 18:14:11 2016 haarg [...] haarg.org - Status changed from 'open' to 'rejected'