in reply to Re: RFC: Simulating Python's @decorators in Perl with Attributes
in thread RFC: Simulating Python's @decorators in Perl with Attributes

Yes, Attribute::Handlers is really badly designed. It uses inheritance in stupid ways and requires things to be put into UNIVERSAL and other nonsense.

I've implemented attributes by not using it and avoided these problems. I actually have a module that is an alternative to Attribute::Handlers that avoids these problems. It isn't on CPAN yet mostly because dealing with the possibility of somebody else having used Attribute::Handlers is a complex mess (and because this was a means to an end so my motivation was more about the module that used this than about this module).

- tye        

  • Comment on Re^2: RFC: Simulating Python's @decorators in Perl with Attributes (inheritance--)

Replies are listed 'Best First'.
Re^3: RFC: Simulating Python's @decorators in Perl with Attributes (inheritance--)
by Arunbear (Prior) on Jun 02, 2013 at 18:40 UTC
    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?
[reply]

      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>; in package Some::Module (for example) is likely to cause uses of Attribute::Handlers or similar attribute-handling modules to be ignored (only for package Some::Module).

      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.

      Note that Attribute::Handlers does 

          push @UNIVERSAL::ISA, 'Attribute::Handlers::UNIVERSAL'

      [download]

      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 cooperates.

      Note that I added some clarifications (inside <ins> 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.

      - tye        

[reply]
[d/l]
[select]

In Section Meditations