Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^3: RFC: Simulating Python's @decorators in Perl with Attributes (inheritance--)

by Arunbear (Parson)
on Jun 02, 2013 at 18:40 UTC ( #1036612=note: print w/ replies, xml ) Need Help??


in reply to Re^2: RFC: Simulating Python's @decorators in Perl with Attributes (inheritance--)
in thread RFC: Simulating Python's @decorators in Perl with Attributes

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?


Comment on Re^3: RFC: Simulating Python's @decorators in Perl with Attributes (inheritance--)
Re^4: RFC: Simulating Python's @decorators in Perl with Attributes (docs and code)
by tye (Cardinal) on Jun 08, 2013 at 20:30 UTC

    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'

    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        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1036612]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2014-08-02 03:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (54 votes), past polls