Bug #113488 for Moose: Duplicate/incompatible attribute definitions produce no error or warning

Thu Mar 31 14:55:29 2016 jim.avera [...] gmail.com - Ticket created

Subject:

Duplicate/incompatible attribute definitions produce no error or warning

The following produces no error or warning: package MyClass; use Moose; has 'foo' => (is => 'ro', isa => 'Math::BigRat'); has 'foo' => (is => 'ro', isa => 'Int'); package main; MyClass->new(foo => 42);

Thu Mar 31 15:01:08 2016 DROLSKY [...] cpan.org - Correspondence added

I wonder how long this bug has existed. Anyway, I agree that this is wrong, and it should be fairly easy to fix (famous last words).

Thu Mar 31 15:01:08 2016 The RT System itself - Status changed from 'new' to 'open'

Sun Sep 11 11:45:28 2016 DROLSKY [...] cpan.org - Correspondence added

RT-Send-CC:

ether [...] cpan.org

On Thu Mar 31 14:55:29 2016, jim.avera@gmail.com wrote: Show quoted text

> The following produces no error or warning: > > package MyClass; > use Moose; > > has 'foo' => (is => 'ro', isa => 'Math::BigRat'); > has 'foo' => (is => 'ro', isa => 'Int'); > > package main; > > MyClass->new(foo => 42);

So I actually looked at how the code handles this, and it _intentionally_ deals with this by removing the old attribute and adding the new one explicitly. I'm not sure why this was coded this way, but I think changing this would break backwards compatibility. Ether, any thoughts on this. It seems like it'd be nice to change this behavior. It's hard to think of a good use case for silently replacing the old attribute.

Sun Sep 25 01:26:44 2016 ether [...] cpan.org - Correspondence added

On 2016-09-11 08:45:28, DROLSKY wrote: Show quoted text

> So I actually looked at how the code handles this, and it > _intentionally_ deals with this by removing the old attribute and > adding the new one explicitly. I'm not sure why this was coded this > way, but I think changing this would break backwards compatibility. > > Ether, any thoughts on this. It seems like it'd be nice to change this > behavior. It's hard to think of a good use case for silently replacing > the old attribute.

It seems that this would never be intentional. However, we often intend to completely override an attribute in a subclass or a role, so we need to differentiate between them. This might be worth throwing out to the mailing list, to see if anyone can think of an objection?