来自current version (0.98)的Moose::Manual::MooseX是行：
我们对未来抱有很高的期望
MooseX::Method::Signatures和MooseX::Declare。但是，这些 模块，经常使用 一些更疯狂的生产 社区成员仍在 标记为alpha以防万一倒退 需要进行不兼容的更改。
我注意到，对于MooseX::Method::Signatures，2009年9月的change log提到删除了“可怕的ALPHA免责声明”。
那么，这些仍然是“阿尔法”吗？
我还会被认为是使用它们的“更疯狂”之一吗？
答案 0 :(得分：12)
我说他们已经准备就绪 - 我在生产中使用 - 但有几件事需要考虑：
MooseX::Declare和依赖关系在编译时几乎完成了所有的魔术。根据程序的大小，您可能会发现从半秒到几秒的额外初始化开销。如果出现此问题，请不要使用MooseX::Declare。
在运行时，主要的开销是类型和参数检查，无论如何你应该（理想情况下）这样做。也就是说，Moose类型约束有一些开销，即强制和更复杂（MooseX :: Types :: Structured-style）约束。如果性能问题，请不要使用这些。
MooseX::Declare和MooseX::Method::Signature's外部语法现在已稳定。但重要的是要知道内部受到极端更改的影响。 （幸运的是，变化更好）
为了给你一个想法，使用从Perl tokenizer（toke.c）窃取的大块C代码来抓取签名本身。在某些情况下，这可能会破坏，因为它实际上并没有解析任何东西。括号内的位使用PPI进行解析，Devel::Declare是为纯Perl设计的，但生成的PPI树会被黑客攻击以获得有用的东西。 MooseX::Declare本身就是一个黑客攻击 - 在看到特定的关键字（例如'role'，'class'，'method'）后，Devel :: Declare-using模块必须手动重写源代码，不与之交互真正的Perl解析器。
极端情况可能导致Perl发生段错误。或严重重写源代码，因此您会遇到语法错误，但不知道在没有-MO::Deparse的情况下导致它们的原因。如果您意外地弄乱了Moops语法，则无法保证模块会检测到这一点并给您一个合理的错误。 ALPHA消息可能已经消失，但这仍然在内部执行 黑暗和可怕的 事情，您应该为此做好准备。
<强>更新
MooseX :: Declare尚未更新，您可能希望查看possibly on the cards等替代方案。就个人而言，我决定坚持使用纯Moose，直到Perl本身开始支持class / method /具有本地语法，即{{3}}。
答案 1 :(得分：7)
我认为这是一个不同观点的问题 - rafl是上述“社区中更疯狂的成员”之一，而Rolsky则更为保守。由你决定你同意谁，我认为最重要的变量是你自己的代码。
MooseX :: Declare是一个很好的代码。它不会随机炸毁你的机器，它对性能来说并不糟糕，它提供了很多很好的东西，同时减少了你必须编写的样板量。但它可能将来发生变化，使得您的代码在更新之前拒绝编译;当它看到无法解析的语法时，它可能会让你的编辑器和其他开发工具感到困惑，它可能会让你的协作者学习一个新的模块来处理你的代码，或者它可能会让你的老板感到厌烦所以任何未来的维护者都必须学习一个新的模块来处理你的代码。哪些事情适用于您，以及在何种程度上？我希望你比我更清楚。
答案 2 :(得分：5)
有些人认为它所基于的MooseX::Delcare，Devel::Declare的成熟度和稳定性，甚至Moose本身尚未为“黄金时间”做好准备。我也知道有两家大公司，每月有数百万访客，他们的生产环境MooseX::Declare。我个人对我Moose提供的堆栈感到满意，并且认为还不需要引入MooseX::Declare。我知道那些我非常尊重的人，如果没有来自MooseX::Declare的陈述性糖，拒绝编写新代码。
所有这一切都可以说，决定生产是否准备就绪，这在很大程度上取决于您的生产环境，您的发展需求和风险品味。如果不妥协，我们无法就任何给定工具与该配置文件的匹配程度做出明智的决定。
答案 3 :(得分：4)
这取决于“生产就绪”的含义。我不会依赖它们，直到它们的速度减慢很多。我喜欢我的制作工具，不需要经常关注外部代码更改，API调整等等。这不是穆斯所特有的，而是任何年轻的项目。
你必须判断对你来说有多重要。在某些情况下，将产品推入生产是一个漫长的过程，所以你必须对这些事情保持谨慎。在另一个极端，某些地方允许您直接在生产服务器上编辑文件。也就是说，在任何人可以告诉您给定的MooseX模块在哪一侧之前，您必须定义容差。
答案 4 :(得分：4)
MooseX :: Method :: Signatures（MXMS）和使用它的MooseX :: Declare不是生产就绪的。这不是因为代码不稳定，而是因为它非常慢。只使用method关键字，没有类型或参数，是500-1000x runtime performance hit over a regular method call。我的Macbook Pro可以使用MXMS每秒执行大约6,000个简单方法调用，使用普通Perl可以执行5,000,000个。
Method::Signatures的性能几乎没有达到要求检查通常花费的成本。语法与MXMS几乎完全相同，它支持Moose（和Mouse）类型。两者都依赖于相同的底层语法修改技术。 （完全披露，我是Method :: Signatures的作者。）
如果您喜欢MooseX :: Declare但希望获得Method :: Signatures的性能，请尝试Method::Signatures::Modifiers。
答案 5 :(得分：3)
MooseX::Declare和MooseX::Method::Signatures运行良好，但根据代码的作用，它们可能会受到严重的惩罚。只需不使用method关键字或使用Method::Signatures::Modifiers即可解决此问题。
与Method::Signatures::Modifiers相比，我看到的性能损失约为2-5倍（5倍主要用于我正在使用的一个特定类）。它似乎主要是编译时间或者可能是第一次初始化，因为当计算时间更长时它会低于2倍。
Method::Signatures::Modifiers有更好的错误，但是当你使用调试器时你必须关闭这个优化（因为它没有看到这些方法，你会看到这些方法，你可以在-MO=Deparse输出中看到）。< / p>
摆脱Perl论点转移地狱可能是值得的。