Skip Menu |

This queue is for tickets about the MooseX-ClassAttribute CPAN distribution.

Report information
The Basics
Id: 111803
Status: open
Priority: 0/
Queue: MooseX-ClassAttribute
People
Owner: Nobody in particular
Requestors: jlmartinez [...] capside.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 0.27
Fixed in: (no value)

History Show all quoted text
  Fri Feb 05 09:30:15 2016 jlmartinez [...] capside.com - Ticket created
Subject: Bug when combining class_has, inheritance and default sub
Hi, I've written a test that demostrates unexpected behaviour when combining class_has, inheritance and default => sub {}. I've specified a class_has "attributes" in a base class, that inspects the class to find it's attributes. If I inherit from the base class, and call attributes on the subclass, I get the correct answer. The bug ocurs when later I call attributes on the base class: it returns the attributes for the subclass. The order in which the "attributes" class_has is called on the classes influences the results of the class_has methods (the first one to get calculated prevails). I would expect that every class (inherited or not) has it's own "attributes" value. I've written a test so you can review if the current behaviour is a bug or not: https://github.com/pplu/MooseX-ClassAttribute/commit/386b3e423710ff957a7de9c70bda2636158309be Best Regards, Jose Luis Martinez JLMARTIN on CPAN
  Sat May 14 11:42:22 2016 DROLSKY [...] cpan.org - Correspondence added
On Fri Feb 05 09:30:15 2016, JLMARTIN wrote: Show quoted text
> Hi, > > I've written a test that demostrates unexpected behaviour when > combining class_has, inheritance and default => sub {}. > > I've specified a class_has "attributes" in a base class, that inspects > the class to find it's attributes. > > If I inherit from the base class, and call attributes on the subclass, > I get the correct answer. The bug ocurs when later I call attributes > on the base class: it returns the attributes for the subclass. > > The order in which the "attributes" class_has is called on the classes > influences the results of the class_has methods (the first one to get > calculated prevails). I would expect that every class (inherited or > not) has it's own "attributes" value. > > I've written a test so you can review if the current behaviour is a > bug or not: https://github.com/pplu/MooseX- > ClassAttribute/commit/386b3e423710ff957a7de9c70bda2636158309be > > Best Regards, > > Jose Luis Martinez > JLMARTIN on CPAN
I'm not really using this module any more, nor do I plan to in the future. Want comaint?
  Sat May 14 11:42:22 2016 The RT System itself - Status changed from 'new' to 'open'
  Sat Dec 10 19:33:24 2016 jlmartinez [...] capside.com - Correspondence added
Hi! Just following up: Show quoted text
> > I'm not really using this module any more, nor do I plan to in the > future. Want comaint?
I'd love to, but I'd need a bit of help on how this issue could be solved (I only wrote the test, but not a fix because I wasn't confident enough with the code, and Moose-meta-stuff)
  Sat Dec 10 23:18:41 2016 ether [...] cpan.org - Correspondence added
On 2016-02-05 06:30:15, JLMARTIN wrote: Show quoted text
> Hi, > > I've written a test that demostrates unexpected behaviour when > combining class_has, inheritance and default => sub {}. > > I've specified a class_has "attributes" in a base class, that inspects > the class to find it's attributes. > > If I inherit from the base class, and call attributes on the subclass, > I get the correct answer. The bug ocurs when later I call attributes > on the base class: it returns the attributes for the subclass. > > The order in which the "attributes" class_has is called on the classes > influences the results of the class_has methods (the first one to get > calculated prevails). I would expect that every class (inherited or > not) has it's own "attributes" value.
I don't think it's a bug. With roles, attributes are applied directly to the class at composition time, but there is no composition in the same manner with a class being subclassed -- the parent class's attributes don't get transferred to the subclass's meta object. Whatever you're trying to do in your real application, this is not the way to do it -- probably easiest is to not use MooseX::ClassAttribute at all, and use a plain old sub that caches data in a hash keyed on the class name.
  Sun Dec 11 12:46:53 2016 DROLSKY [...] cpan.org - Correspondence added
So I finally looked at the code example. On 2016-02-05 08:30:15, JLMARTIN wrote: Show quoted text
> Hi, > > I've written a test that demostrates unexpected behaviour when > combining class_has, inheritance and default => sub {}. > > I've specified a class_has "attributes" in a base class, that inspects > the class to find it's attributes.
If this is code you wrote for real use it's awfully odd. You can already write Foo->meta->get_all_attributes. There's no need for an extra class attribute to store the meta-attr objects. But maybe this was just for the example code? Show quoted text
> > If I inherit from the base class, and call attributes on the subclass, > I get the correct answer. The bug ocurs when later I call attributes > on the base class: it returns the attributes for the subclass. > > The order in which the "attributes" class_has is called on the classes > influences the results of the class_has methods (the first one to get > calculated prevails). I would expect that every class (inherited or > not) has it's own "attributes" value. > > I've written a test so you can review if the current behaviour is a > bug or not: https://github.com/pplu/MooseX- > ClassAttribute/commit/386b3e423710ff957a7de9c70bda2636158309be
I would tend to agree with ether that this isn't really a bug. To "fix" this you'd have to explicitly copy the class attributes when extending a parent. That is in fact what Class::Data::Inheritable does, and I don't think it's entirely crazy. That said, I really don't recommend using this module. Class attributes are more trouble than they're worth. Find a different design that eliminates the need for them entirely.