perl - Moose 与 MooseX::Declare

Question

后奏

MooseX::Declare 将不再被任何人推荐，因为它依赖于 Devel::Declare，它达到了它的目的，但它本身已经过时了。此时，如果有人想要 MX::D，他们应该查看 Moops

原创

假设我已经对旧式 Perl OO 有相当的了解，并且假设我要编写一些 Moose 风格的新代码(是的，我知道这会影响性能)，我想知道是否更深入地了解任何一个兔子洞，我会希望我选择了另一条路吗？各位僧侣能否用 Moose 的相对优点来启发我？与 MooseX::Declare (或其他？)。还有它们的可互换性，一个用于一个类(class)，另一个用于另一个类(class)，我应该选择切换吗？

(p.s.我可以连续回答这个问题，但是我认为一个格式良好的答案可能能够避免主观性)

Answer 1

MooseX::Declare 基本上是 Moose 的语法糖层。对于经过解析器的所有内容，它们在生成的内容上是相同的。 MooseX::Declare 只是产生了更多的内容，而编写的内容却少了很多。

作为一个喜欢 MooseX::Declare 的语法但仍然喜欢用纯 Moose 编写我的所有代码的人来说，权衡主要是在开发和可维护性方面。

比较时注意事项的基本列表:

MooseX::Declare 有更简洁的语法。在普通的旧 perl 对象(PO​​PO？)中需要几百行的东西，在 Moose 中可能需要 50 行，在 MooseX::Declare 中可能需要 30 行。 MooseX::Declare 的代码对我来说也更具可读性和优雅性。

MooseX::Declare 意味着您免费拥有 MooseX::Types 和 MooseX::Method::Signatures。这导致了非常优雅的 method foo(Bar $bar, Baz $baz) { ... }导致人们在使用 Ruby 几年后重新回到 Perl 的语法。

MooseX::Declare 的一个缺点是一些错误消息比 Moose 更神秘。 TypeConstraint 验证失败的错误可能发生在 MooseX::Types::Structured 的好几层，并且从那里到达代码中你破坏的地方，对于系统新手来说可能很困难。驼鹿也有这个问题，但程度较轻。

龙在 MooseX::Declare 中的隐藏位置可能与它们在 Moose 中的隐藏位置略有不同。 MooseX::Declare 努力绕过已知的 Moose 问题(例如 with() 的时间)，但引入了一些需要注意的新地方。例如，MooseX::Types 与 Moose 的原生 Stringy 类型[^1] 有一组完全不同的问题。

MooseX::Declare 的性能又一次受到冲击。 MooseX::Declare 开发人员和人们都知道这一点(我相信有几个工作值(value))。

MooseX::Declare 为 Moose 添加了更多依赖项。我添加这个是因为人们已经提示 Moose 的依赖列表大约有 20 个模块。 MooseX::Declare 在此基础上增加了另外 5 个直接依赖项。然而，根据 http://deps.cpantesters.org/ 的总列表是 Moose 27，MooseX::Declare 91。

如果您愿意使用 MooseX::Declare，最好的部分是您可以在每个类(class)之间进行交换。您无需在项目中重新选择一个。如果这个类在 Moose 中因为性能需要更好，或者它由初级程序员维护，或者安装在更严格控制的系统上。你可以这样做。如果该类可以从 MooseX::Declare 语法的额外清晰度中受益，那么您也可以这样做。

希望这有助于回答这个问题。

[^1]:有人说少，有人说多。老实说，Moose 核心开发人员还在争论这一点，并没有正确的答案。