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