My team recently decided to move away from MooseX::Declare. Is using MooseX::Method::Signatures on its开发者_Go百科 own the best alternative?
Courtesy of Jon Rockway, who is too lazy to change his proxy:
My take is that for ease of debugging, it’s best not to use either. They don’t introduce many problems of their own (the slow startup time is Class->meta->make_immutable, which you would do anyway), but they do introduce problems when interacting with other tools. Devel::Cover, Devel::NYTProf, perlcritic, perltidy, etc., require various degrees of tweaking in order to be usable. You have to weigh the syntax sugar against the inability to use certain tools as easily.
So I think there are various options:
- MooseX::Declare – less typing; ease in being accurate; ease of extensibility
- MooseX::Method::Signatures – a little more typing, a little less accuracy; you have to worry about “use namespace::autoclean” or “no Moose”, you have to worry about make_immutable, you have to return a true value, etc.
- MooseX::Params::Validate – now we’re back to normal Perl; same validations as MX::Method::Signatures, and same drawbacks. But now all your tools work. Only problem is that the syntax is ugly – my eyes, the goggles do nothing!
- Parms::Util – simple way to get “correct” validations, acceptable syntax, but less flexible; does not integrate with MooseX::Types like MX::Params::Validate Doing it manually – simple, usually correct, easy to understand. But it’s easy to be tempted into being lazy; allow a CODE ref, but not objects with a CODE overload; “ref $foo” instead of “ref $foo && blessed $foo && $foo->isa(‘ClassName’); etc.
So really, they’re all bad in their own special fun ways. Lately I have been doing a combination of manual validation and Params::Util, but I’m not willing to say that’s the best way to do things. I’m going to weight my “best practice” towards MX::Types + MX::Params::Validate, but for some reason, I’m not motivated to use it myself.
--Jon
精彩评论