Skip Menu |
 

This queue is for tickets about the Moose CPAN distribution.

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

People
Owner: Nobody in particular
Requestors: jim.avera [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.1605
Fixed in: (no value)



Subject: Duplicate/incompatible attribute definitions produce no error or warning
Download (untitled) / with headers
text/plain 208b
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);
Download (untitled) / with headers
text/plain 133b
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).
RT-Send-CC: ether [...] cpan.org
Download (untitled) / with headers
text/plain 708b
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.
Download (untitled) / with headers
text/plain 752b
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?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.