john napiorkowskihttp://cpanratings.perl.org/dist/MooseX-MethodAttributes#6376
Rating: 5 stars
To help people figure out the "why?" here, my understanding is that even though in general the Perl community is moving away from method attributes, there's a lot of code in the wild that uses it, so the Moose community went to a lot of trouble (mostly the main author of this package) to bend over backwards and support something that few people using Moose actually need, but was felt needed for compatibility reasons. I think the main reason for being for this (please someone correct me if I am wrong) is to support the Catalyst transition to Moose. So I feel it really shows how hard the Catalyst team is trying to maintain backward compatibility, even with as huge a change as rewriting the underlying bits in a new framework.
My recommendation to you is to stay away from method attributes; but if you have legacy code that uses then and you want to transition to Moose, this will help a lot.john napiorkowskiSam Vilainhttp://cpanratings.perl.org/dist/MooseX-MethodAttributes#5864
There are those who believe that all language features should be introspectable by an consistent object-oriented interface, and then those who believe that piecemeal procedural interfaces are sufficient.
If you're not sold on the first idea, you might reach the conclusion of Pista. In which case continue to use the old interfaces of yesterday, and hope that people don't ever call your code legacy as soon as you write it.Sam Vilainhdphttp://cpanratings.perl.org/dist/MooseX-MethodAttributes#5734
This is a perfectly reasonable interface to code attributes inside the Moose metaprotocol. However, since I haven't actually used it (just code that uses it), I won't give it a numeric rating.
Dear Pista Palo: while you're at it, also rate POE 1 star for being more code than "while (1) {}", rate Template::Toolkit 1 star for being more code than sprintf, and rate DBI 1 star for being more code than `mysql -e "select * from mytable" mydb`.hdp