Bug #96066 for Class-Data-Inheritable-Translucent: This is a duplicate of Class::Data::Accessor

On Thu May 29 18:09:44 2014, mst@shadowcat.co.uk wrote: Show quoted text
Very close but not quite. It has two advantages over C::D::A -- the use of Sub::Name (e.g. for better profiling - so that meaningful accessor names are shown rather than just __ANON__) and support for non hash-based objects. (Both modules seem to have appeared at almost exactly the same time, btw: C::D::A in late Nov 2005, with C::D::I::T only a fortnight or so later in mid-Dec. The original author of C::D::I::T may have searched for existing modules doing the same thing, found none, and so made his own, and never noticed that another one slipped out while he was writing his?) C::A::G came along in mid-2006 and does more than the above two. I see that its 'inherited' type is the same thing again, and whilst it does support Sub::Name, it still doesn't support non hash-based objects (I haven't looked at its other features, but the 'inherited' type at least is documented to die if you try to set an object variable on a non hash-based object). C::D::I::T also has another feature that I find useful which neither C::D::A nor C::A::G have: you can set an overridden object attribute's value to the undefined value to wipe it out and reinherit the class default. E.g. Foo->colour('red'); my $obj = Foo->new(); $obj->colour('blue'); $obj->colour(undef); print $obj->colour(); prints 'red', whereas C::D::A and C::A::G both print undef. (You can, of course, write $obj->colour(Foo->colour()) to reset the object attribute to the class attribute value, but that's only copying the class attribute's current value so won't see any subsequent changes to it.) C::D::I::T is also 'friendly' like Class::Accessor (but unlike Class::Data::Inheritable, despite requests in CPAN RT#6281 and #51228) in not overwriting existing existing (accessor) methods, whereas C::D::A and C::A::G just blindly overwrites them. I will certainly add a note to C::D::I::T's documentation mentioning the other modules (C::A::G in particulr, since C::D::A is itself deprecated in favour of C::A::G (or Moose)), but I would not personally want to switch away from using it without C::A::G at least having the means to 'reset' a previously overridden attribute on an object.

On Sat, May 31, 2014 at 12:57:23PM -0400, Steve Hay via RT wrote: Show quoted text
In ways that I'm not sure I'd want, but can see the use of. Show quoted text
Which makes CDA/CAG usable as a drop-in replacement in places CDIT isn't. ISTR C::A didn't used to be 'friendly' and its becoming so broke a bunch of code. This is a trade-off though; Moo(se) are 'friendly'. Possibly worth documenting for people who care about that more than they care about the other things CDIT brings to the table. Show quoted text
I've largely concluded that mutable class data is a terrible idea anyway, and these days would use an attribute with a lazy builder and a clearer to get class-default-object-overridable-with-reset-option. i.e. has foo => (is => 'lazy', builder => sub { 3 }, clearer => 1); which installs the 'sub { 3 }' as _build_foo, so subclasses can simply define their own if they want a default class-level default. However, the above is meant to be informational rather than an argument for conversion to that approach, and I concur that adding a note in the docs and leaving the module be is probably correct. Actually, given how informative your reply was, I think linking to this ticket from the docs might also be a good thing, but I'll leave that choice up to you :) -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.