Moose 与 MooseX::声明
POSTLUDE
MooseX::Declare 将不再被任何人推荐，因为它依赖于 Devel::Declare，后者达到了其目的，但本身已经过时了。此时，如果有人想要 MX::D，他们应该查看 Moops
ORIGINAL
假设我已经对旧式 Perl OO 有相当的了解，并且假设我将用 Moose 的某种风格编写一些新代码（是的，我知道这会对性能造成影响），我想知道是否会更深入地了解这两个兔子洞，我会希望我选择了另一条路吗？你们僧侣们能否告诉我 Moose 与. MooseX::Declare （或其他一些？） 。另外，它们是可以互换的，一个用于一个类，另一个用于另一个类，我是否应该选择切换。
（附注：我可以继续回答这个问题，但我认为一个良好的答案可能能够避免主观性）
POSTLUDE
MooseX::Declare would no longer be recommended by anyone as it relies on Devel::Declare which served its purpose but is itself obsolete. At this point if anyone wants MX::D they should look at Moops
ORIGINAL
Assuming I already have a decent knowledge of old-style Perl OO, and assuming I am going to write some new code in some flavor of Moose (yes, I understand there is a performance hit), I was wondering if deeper down either rabbit hole, am I going to wish that I had chosen the other path? Could you SO-monks enlighten me with the relative merits of Moose vs. MooseX::Declare (or some other?). Also how interchangeable they are, one for one class and the other for another, should I choose to switch.
(p.s. I would be ok cw-ing this question, however I think a well formed answer might be able to avoid subjectivity)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
MooseX::Declare 基本上是 Moose 之上的语法糖层。对于经过解析器的所有内容，它们产生的结果都是相同的。 MooseX::Declare 只是产生了更多的内容，而编写的内容却少了很多。
作为一个喜欢 MooseX::Declare 语法但仍然喜欢用普通 Moose 编写所有代码的人来说，权衡主要是在开发和开发上。可维护性方面。
比较它们时需要注意的基本列表：
MooseX::Declare 具有更加简洁的语法。在普通的旧 Perl 对象（POPO？）中需要几百行的东西，在 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 的几层深处，对于刚接触该系统的人来说，从那里到达代码中被破坏的位置可能很困难。 Moose 也有这个问题，但程度较轻。
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 中更好，或者它由初级程序员维护，或者安装在更严格控制的系统上。你可以这么做。如果该类可以受益于 MooseX::Declare 语法的额外清晰度，您也可以这样做。
希望这有助于回答这个问题。
[^1]：有的说少，有的说多。老实说，Moose 核心开发人员仍在争论这个问题，并且没有正确的答案。
MooseX::Declare is basically a sugar-layer of syntax over Moose. They are, for everything past the parser, identical in what they produce. MooseX::Declare just produces a lot more of it, with a lot less writing.
Speaking as someone who enjoys the syntax of MooseX::Declare but still prefers to write all of my code in plain Moose, the tradeoffs are mostly on the development & maintainability side.
The basic list of items of note when comparing them:
MooseX::Declare has much more concise syntax. Things that take several hundred lines in plain old perl objects (POPO?), may take 50 lines in Moose, may take 30 lines in MooseX::Declare. The code from MooseX::Declare is to me more readable and elegant as well.
MooseX::Declare means you have MooseX::Types and MooseX::Method::Signatures for free. This leads to the very elegant
method foo(Bar $bar, Baz $baz) { ... }syntax that caused people to come back to Perl after several years in Ruby.A downside to MooseX::Declare is that some of the error messages are much more cryptic than Moose. The error to a TypeConstraint validation failure may happen several layers deep in MooseX::Types::Structured and getting from there to where in your code you broke it can be difficult for people new to the system. Moose has this problem too, but to a lesser degree.
The places where the dragons hide in MooseX::Declare can be subtly different than where they hide in Moose. MooseX::Declare puts in an effort to walk around known Moose issues ( the timing of
with()for example) but introduces some new places to be aware of. MooseX::Types for example have a wholly different set of problems from Moose's native Stringy types[^1].MooseX::Declare has yet another performance hit. This is known to the MooseX::Declare developers and people are working on it (for several values of working I believe).
MooseX::Declare adds more dependencies to Moose. I add this one because people complain already about Moose's dependency list which is around 20 modules. MooseX::Declare adds around another 5 direct dependencies on top of that. The total list however according to http://deps.cpantesters.org/ is Moose 27, MooseX::Declare 91.
If you're willing to go with MooseX::Declare, the best part is you can swap between them at the per-class level. You need not pick one over the over in a project. If this class is better in Moose because of Performance needs, or it's being maintained by Junior programmers, or being installed on a more tightly controlled system. You can do that. If that class can benefit from the extra clarity of the MooseX::Declare syntax you can do that too.
Hope this helps answer the question.
[^1]: Some say fewer, some say more. Honestly the Moose core developers are still arguing this one, and there is no right answer.
您可能感兴趣的一个小方面，我也可能对这个问题的答案感兴趣：我在 MooseX::Declare 中遇到的主要问题（这在我的具体情况下很重要）是我无法将我的应用程序打包为可执行文件，既不使用 PAR::Packer 也不使用 ActiveState PerlApp。
然后我使用 https://github.com/komarov/undeclare/blob/master/ undeclare.pl 返回 Moose 代码。
One minor aspect that may interest you, and I may as well be interested by an answer to this : the main problem I had with MooseX::Declare, which was important in my specific case, was that I was unable to pack my application as an executable, neither with PAR::Packer nor ActiveState PerlApp.
I then used https://github.com/komarov/undeclare/blob/master/undeclare.pl to go back to Moose code.
如上面所写
MooseX::Declare 的其他问题：
- 可怕的错误消息（真的，没用。除非你使用 Method::Signatures::Modifiers ）
- 性能受到影响（正如您所指出的），但在我看来并不小。 （我们介绍了一些大型的现实应用程序）
- TryCatch 的问题（如果您使用它，请参阅：https://rt .cpan.org/Public/Bug/Display.html?id=82618）
- 混合环境中的一些不兼容性（MooseX - 非 Moose 环境，例如 $VERSION 检查失败）
如果您不需要 MooseX 的“语法糖”，请不要使用它。根据您要执行的任务，我会使用“从下到上”，例如。
1. 鼠标+方法::签名
2. 驼鹿
3.然后也许是MooseX，
具体取决于你想要什么。
按照这个顺序升级并不太复杂。然而，如果你真的需要 MooseX，我宁愿建议你寻找其他一些面向对象的开发语言，提供大部分内置功能（例如 horribile dictu Ruby 或 Python），并且那些找不到的东西，你或许没有也能活下去。
As written above
other problems with MooseX::Declare:
- terrible error messages ( really, useless. unless you use Method::Signatures::Modifiers )
- performance hit ( as You have noted ), but in my opinion not small. ( we profiled some big real-life apps )
- problem with TryCatch ( if U use that, see: https://rt.cpan.org/Public/Bug/Display.html?id=82618 )
- some incompatibilities in mixed ( MooseX - non-Moose environment, eg. failed $VERSION check )
If You do not need the 'syntactic sugar' of MooseX, do not use it. Depending on the task You are into, I'd use from 'bottom-to-top', eg.
1. Mouse+Mehod::Signatures
2. Moose
3. then perhaps MooseX
depending on what you want.
Upgrading is not too complicated in this order. However, if You come to the point that You really need MooseX, I'd rather suggest You looking for some other, OO-wise developed language that offer most of the features in-box ( eg. horribile dictu Ruby or Python ), and those, that are not found, You perhaps you can live without.
如果你真的想要驼鹿，请考虑从下到上的方法，从较少的糖开始。我更喜欢首先使用 Mouse + Method::Signatures。我的场景是，我坐在后端，我们需要很少的对象、浅层次结构，但有时需要快速访问器 - 那么我们仍然可以回退到 XSAccessor。鼠标+方法签名似乎是语法帮助和速度之间相当好的折衷方案。如果我的设计确实需要更多，那么只需升级到 Moose 即可。
我可以通过 MooseX::Declare 来确认速度损失，不仅可以通过简单的访问器基准测试 ( https:/ /metacpan.org/pod/App::Benchmark::Accessors ），而且在现实生活中的应用程序。这与神秘的错误消息相结合，规则 MooseX::Declare 出局。
If You really want Moose, consider a bottom-to-top approach starting with the less sugar. I prefer using Mouse + Method::Signatures first. My scenario is that I am sitting on the backend where we need very few objects, shallow hierarchy, but sometimes fast accessors - then we can still fall back to XSAccessor. Mouse+Method Signatures seem to be a rather good compromise between syntactic help and speed. If my design really needs more, then simply upgrade to Moose.
I can confirm the speed penalty with MooseX::Declare not only with simple accessor benchmarks ( https://metacpan.org/pod/App::Benchmark::Accessors ), but also in real-life application. This combined with cryptic error messages rules MooseX::Declare out.