是否仍建议使用 MooseX::Method::Signatures，或者是否有更好的替代方案？
我的团队最近决定放弃 MooseX::Declare。单独使用 MooseX::Method::Signatures 是最好的选择吗？
My team recently decided to move away from MooseX::Declare. Is using MooseX::Method::Signatures on its own the best alternative?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由 Jon Rockway 提供，他懒得更改他的代理：
我的看法是，为了便于调试，最好不要使用其中任何一个。它们本身并没有引入很多问题（缓慢的启动时间是 Class->meta->make_immutable，无论如何你都会这样做），但它们在与其他工具交互时确实引入了问题。 Devel::Cover、Devel::NYTProf、perlcritic、perltidy 等需要进行不同程度的调整才能使用。您必须权衡语法糖与无法轻松使用某些工具的问题。
所以我认为有多种选择：
手动完成——简单、通常正确、易于理解。但人很容易被诱惑变得懒惰。允许 CODE 引用，但不允许具有 CODE 重载的对象； “ref $foo”而不是“ref $foo &&”祝福 $foo && $foo->isa('类名');等等。
所以说真的，他们都有自己特别有趣的坏处。最近我一直在结合手动验证和 Params::Util，但我不愿意说这是最好的方法。我将把我的“最佳实践”放在 MX::Types + MX::Params::Validate 上，但由于某种原因，我自己没有动力使用它。
——乔恩
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:
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