片尾曲
MooseX :: Declare将不再被任何人推荐，因为它依赖于Devel :: Declare，它实现了它的目的，但它本身已经过时了。此时，如果有人想要MX :: D，他们应该查看Moops
ORIGINAL
假设我已经对旧式Perl OO有了不错的认识，并且假设我要用某种形式的Moose编写一些新的代码（是的，我知道有一个性能损失），我想知道是否更深层次的兔子洞，我是否希望我选择了另一条道路？你能不能用Moose与MooseX::Declare（或其他一些？）的相对优点来启发我。另外，如果我们选择转换，它们是如何互换的，一对一和另一个，我应该选择切换。
（p.s。我可以提出这个问题，但我认为一个结构合理的答案可能会避免主观性）
答案 0 :(得分：19)
MooseX :: Declare基本上是Moose语法的糖层。对于解析器之外的所有内容，它们都是相同的。 MooseX :: Declare只会产生更多的东西，而写作却少得多。
作为一个喜欢MooseX :: Declare语法的人，但仍然喜欢用简单的Moose编写我的所有代码，这些权衡主要取决于开发和开发。可维护性方面。
比较它们时的基本项目清单：
MooseX :: Declare具有很多更简洁的语法。在普通的旧perl对象（POPO？）中需要几百行的东西，在Moose中可能需要50行，在MooseX中可能需要30行:: Declare。 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开发人员来说是已知的，人们正在上工作（对于我认为的几个工作值）。
MooseX :: Declare为Moose添加了更多依赖项。我添加了这个，因为人们已经抱怨Moose的依赖列表，大约有20个模块。 MooseX :: Declare在其上添加了另外5个直接依赖项。但根据http://deps.cpantesters.org/的总列表是Moose 27，MooseX :: Declare 91。
如果您愿意使用MooseX :: Declare，最好的部分是您可以在每个级别上进行交换。你不需要在项目中选择一个。如果这个类在Moose中因性能需求更好，或者由Junior程序员维护，或者安装在更严格控制的系统上。你可以做到这一点。如果该类可以从MooseX :: Declare语法的额外清晰度中受益，那么您也可以这样做。
希望这有助于回答这个问题。
[^ 1]：有人说更少，有些人说更多。老实说，Moose核心开发人员仍在争论这个问题，而且没有正确的答案。
答案 1 :(得分：3)
您可能感兴趣的一个小方面，我也可能对这个答案感兴趣：我对MooseX :: Declare的主要问题，在我的具体案例中很重要，就是我无法打包我的应用程序作为可执行文件，既不是PAR :: Packer也不是ActiveState PerlApp。
然后我使用https://github.com/komarov/undeclare/blob/master/undeclare.pl返回Moose代码。
答案 2 :(得分：0)
如上所述 MooseX :: Declare的其他问题： - 可怕的错误消息（真的，没用。除非你使用Method :: Signatures :: Modifiers） - 性能上升（正如你所注意到的），但在我看来并不小。 （我们描述了一些大型的现实应用程序） - TryCatch的问题（如果你使用它，请参阅：https://rt.cpan.org/Public/Bug/Display.html?id=82618） - 混合中的一些不兼容性（MooseX - 非Moose环境，例如，$ VERSION检查失败）
如果您不需要MooseX的'语法糖'，请不要使用它。根据您所从事的任务，我将使用“自下而上”，例如。 1.鼠标+ Mehod ::签名 麋 3.然后也许是MooseX
取决于你想要的东西。
按此顺序升级并不太复杂。但是，如果你真的需要MooseX，我宁愿建议你寻找其他一些OO智能开发的语言，提供大多数内置功能（例如，可怕的Ruby或Python），以及那些，没有找到，你也许你可以没有。
答案 3 :(得分：0)
如果你真的想要Moose，那么从低糖开始考虑采用自下而上的方法。我更喜欢先使用Mouse + Method :: Signatures。我的情况是我坐在后端，我们需要很少的对象，浅层次，但有时快速访问 - 然后我们仍然可以回到XSAccessor。鼠标+方法签名似乎是句法帮助和速度之间的一个相当好的折衷。如果我的设计真的需要更多，那么只需升级到Moose。 我可以使用MooseX :: Declare来确认速度惩罚，不仅可以使用简单的访问器基准（https://metacpan.org/pod/App::Benchmark::Accessors），还可以在实际应用程序中使用。这与MooseX ::声明出来的神秘错误消息规则相结合。