Your alternative to Attribute::Handlers sounds very useful. Perhaps the first release could just come with a warning that it may not play well with existing code that uses Attribute::Handlers (If I understood that part correctly)? Or maybe just 'release' it on Github?
Re^3: RFC: Simulating Python's @decorators in Perl with Attributes (inheritance--)
Replies are listed 'Best First'.
I was looking for something and not finding it and tripped over some stuff that reminded me that I might be nearby to this work so I found it. I was happy to find that I had already written a decent summary of the problems with Attribute::Handlers and even published that as part of something I put on CPAN: Devel::Init - Compatibility with Attribute::Handlers, etc. I'll copy it here for y'all's convenience:
The design of attributes.pm encourages complex and hard-to-coordinate
usage patterns that are (unfortunately) well demonstrated by
Attribute::Handlers. Although early drafts of Devel::Init
included complex code to try to support compatibility with
Attribute::Handlers, it was determined that it is more appropriate for
such compatibility to be handled in a more sane manner via changes to
attributes.pm (or at least some other module).
Devel::Init uses a much, much simpler approach for supporting attributes
and also supports attributes::get() (which Attribute::Handlers appears
to have completely ignored).
Using use Devel::Init qw<:Init>;
is likely to cause
uses of Attribute::Handlers or similar attribute-handling modules
to be ignored .
This is because attributes.pm basically does
Some::Module->can('MODIFY_CODE_ATTRIBUTES') and Devel::Init
directly defines Some::Module::MODIFY_CODE_ATTRIBUTES() (and
Some::Module::FETCH_CODE_ATTRIBUTES) while Attribute::Handlers
makes complicated use of multiple layers of inheritance. Only one
MODIFY_CODE_ATTRIBUTES() method is found and used by attributes.pm,
and it will be the one defined by Devel::Init.
which means that every single class now magically inherits from
Attribute::Handlers::UNIVERSAL. This is an extremely heavy-handed
way to implement anything.
Devel::Init will cooperate with an attribute-handling module that
directly defines a Some::Module::MODIFY_CODE_ATTRIBUTES() method
provided either that Devel::Init is loaded second or the other module also
Note that I added some clarifications (inside tags).
It would have been much, much better if attributes.pm had made use of a global array of attribute handlers (per package) instead of single global attribute handling subroutines per package (and per operation type). Then a design as heavy-handed and misguided as Attribute::Handlers probably never would have been created. Especially bad was using ->can(), which just opens a big can of worms when trying to get multiple sources of attribute handlers to cooperate.
You can see the mess needed to deal with the use of ->can() after the __END__ of Init.pm. But I realize that it doesn't even deal with the UNIVERSAL nonsense because 'UNIVERSAL' is just implicitly in @ISA.
But these minor mis-steps by the author(s) of attributes.pm not only pale but blanch in comparison to the wildly inappropriate choices made by the author(s) of Attribute::Handlers.
I lack the needed tolerances for trying to get attributes.pm improved. Simultaneously being ignored by the few, over-busy key people who need to accept what you have done mixes so irritatingly with not quite being able to ignore the functionaries on the list who don't seem to actually understand the work being done but have suggestions about how one could e-mail about the code one has written more effectively. Trying to submit a 3-line patch that fixes a fundamental bug in the basic working of hashes only takes about a decade when I try to do it via such means. Doing something actually difficult like transitioning to a different base methodology in attributes.pm and figuring out how much backward compatibility is enough would never actually succeed.
But I do plan to upload an alternative to Attribute::Handlers.