MooseX::Declare 和 MooseX::Method::Signatures 生产准备好了吗？
来自当前版本 (0.98) Moose::Manual::MooseX 是以下几行：
我们对未来充满希望
MooseX::Method::Signatures和MooseX::Declare。然而，这些 模块，同时经常使用 由一些更疯狂的人制作 社区成员，仍然 标记 alpha 以防万一向后 需要进行不兼容的更改。
我注意到对于 MooseX::Method::Signatures< /a> 2009 年 9 月的更改日志提到了删除“可怕的 ALPHA 免责声明”。
那么，这些仍然是“alpha”吗？
我还会被认为是使用它们的“更疯狂”的人之一吗？
From the current version (0.98) of the Moose::Manual::MooseX are the lines:
We have high hopes for the future of
MooseX::Method::SignaturesandMooseX::Declare. However, these
modules, while used regularly in
production by some of the more insane
members of the community, are still
marked alpha just in case backwards
incompatible changes need to be made.
I noticed that for MooseX::Method::Signatures the change log for September 2009 mentions the removal of the "scary ALPHA disclaimer".
So, are these still "alpha"?
Would I still be considered one of the "more insane" to use them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我想说它们已经准备好生产了 - 我在生产中使用它们 - 但有几件事需要考虑：
性能
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 本身开始原生支持 class/method/has 语法，即 可能在卡片上。
I'd say they are production ready - I'm using them in production - but there are several things to consider:
Performance
MooseX::Declareand dependencies do almost all of their magic at compile time. Depending on the size of your program, you might find anywhere from half a second to several seconds of additional initialization overhead. If this a problem, don't use MooseX::Declare.At runtime, the main overhead is type and argument checking, which you should (ideally) be doing anyway. That said, Moose type constraints have some overheads, namely coercion and the more complex (MooseX::Types::Structured-style) constraints. Don't use these if performance is an issue.
Stability
MooseX::Declare and MooseX::Method::Signature's external syntax is now stable. But it is important to know that the internals are subject to extreme change. (fortunately, changes for the better)
To give you an idea, the signature itself is grabbed using a big block of C code stolen from the Perl tokenizer (toke.c). This can break in some situations since it isn't actually parsing anything. The bit inside the brackets is parsed using PPI, which is designed for pure Perl, but the resulting PPI tree is then hacked up to get something useful. Devel::Declare itself is a hack - after it sees specific keywords (e.g. 'role', 'class', 'method') the Devel::Declare-using module must rewrite the source code by hand, with no interaction with the real Perl parser.
Corner cases may cause Perl to segfault. Or rewrite the source code badly, so you get syntax errors but have no idea what's causing them without
-MO::Deparse. If you mess up the MooseX::Declare syntax by accident, there is no guarantee that the module will detect this and give you a sensible error. The ALPHA message may have gone, but this is still doing dark and scary things internally, and you should be prepared for that.UPDATE
MooseX::Declare has not been updated much, and you may wish to look at alternatives such as Moops. Personally, I have decided to stick with pure Moose until Perl itself begins to support class/method/has syntax natively, which is possibly on the cards.
我认为这是一个观点不同的问题——拉菲尔是前面提到的“社区中更疯狂的成员”之一，而罗尔斯基则更为保守。由你来决定你同意谁，而且我认为最重要的变量是你自己的代码。
MooseX::Declare 是很好的代码。它不会随机炸毁您的机器，性能也不会很差，并且它提供了很多漂亮的东西，同时减少了您必须编写的样板文件的数量。但它可能将来会发生变化，导致您的代码在更新之前拒绝编译；当你的编辑器和其他开发工具看到它无法解析的语法时，它可能会让你的编辑器和其他开发工具感到困惑，它可能会因为让你的合作者学习一个新模块来使用你的代码而惹恼他们，或者它可能会因为让你的老板生气而让他们生气。因此任何未来的维护者都必须学习一个新模块来使用您的代码。其中哪些适用于您，适用于什么程度？我希望你比我更了解。
I think it's a matter of differing perspectives as much as anything -- rafl is one of the aforementioned "more insane members of the community" while Rolsky is more conservative. It's up to you to decide who you agree with, and really I think that the most important variable is your own code.
MooseX::Declare is good code. It won't randomly blow up your machine, it's not awful for performance, and it offers a lot of nifty stuff while reducing the amount of boilerplate that you have to write. But it might change in the future, making your code refuse to compile until it's updated; it might make your editor and other development tools confused when it sees syntax that it can't parse, it might piss off your collaborators by making them learn a new module to work with your code, or it might piss off your boss by making it so any future maintainer has to learn a new module to work with your code. Which of those things apply to you, and to what degree? You know better than I do, I hope.
有些人认为
MooseX::Delcare、它所基于的Devel::Declare甚至Moose本身的成熟度和稳定性还没有准备好迎接“黄金时间”。我还知道有两家每月有数百万访问者的大公司，他们的生产环境中有MooseX::Declare。我个人对Moose提供的堆栈感到满意，并且认为还没有必要引入MooseX::Declare。我认识一些我非常尊重的人，他们拒绝在没有MooseX::Declare的声明性糖分的情况下编写新代码。所有这一切都意味着，决定某个东西是否已准备好投入生产在很大程度上取决于您的生产环境、您的开发需求和风险偏好。如果不站在您的立场上，我们不可能就任何给定工具与该配置文件的匹配程度做出明智的决定。
There are people who feel that the maturity and stability of
MooseX::Delcare,Devel::Declareon which it's based, or evenMooseitself are not yet ready for "prime time". I also know of two large companies with millions of visitors a month, who haveMooseX::Declarein their production environment. I personally am happy with the stack I am provided withMooseand do not see a need yet to bring inMooseX::Declare. I know people who's opinion I deeply respect who refuse to write new code without the declarative sugar fromMooseX::Declare.All of this is to say, the decision on whether something is or is not production ready is highly dependent upon your production environment, your development needs, and taste for risk. Without being in your shoes we can't possibly give an informed decision as to how well any given tool matches that profile.
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 的性能，请尝试 方法::Signatures::Modifiers。
MooseX::Method::Signatures (MXMS), and MooseX::Declare which uses it, is not production ready. This is not because the code isn't stable, but because it is appallingly slow. Simply using the
methodkeyword, no types or arguments, is a 500-1000x runtime performance hit over a regular method call. My Macbook Pro can do about 6,000 simple method calls per second using MXMS vs 5,000,000 with plain Perl.Method::Signatures, in contrast, has almost no performance hit above what it would normally cost to do the requested checks. The syntax is almost exactly the same as MXMS and it supports Moose (and Mouse) types. Both rely on the same underlying syntax modifying technique. (Full disclosure, I am the author of Method::Signatures.)
If you like MooseX::Declare but want the performance of Method::Signatures, try Method::Signatures::Modifiers.
这取决于您所说的“生产就绪”是什么意思。在他们的速度减慢很多之前我不会依赖他们。我喜欢我的生产资料不需要经常关注外部代码更改、API 调整等。这并不是 Moose 特有的事情，而是任何年轻的项目。
你必须判断这对你有多重要。在某些情况下，将产品投入生产是一个漫长的过程，因此您必须谨慎对待此类事情。在另一个极端，有些地方允许您直接在生产服务器上编辑文件。也就是说，在任何人能够告诉您给定 MooseX 模块位于哪一侧之前，您必须定义您的容差。
It depends on what you mean by "production ready". I wouldn't depend on them until their velocity slows down quite a bit. I like my production stuff to not need frequent care from external code changes, API adjustments, and so on. That's not something particular to Moose, but any young project.
You have to judge how much that matters to you. In some situations, pushing stuff into production is a lengthy process, so you must be circumspect with such things. At the other extreme, some places let you edit files directly on the production server. That is, you have to define your tolerance before anyone can tell you which side a given MooseX module is on.
MooseX::Declare和MooseX::Method::Signatures运行良好，但根据代码的用途，它们可能会产生非常严重的惩罚。只需不使用method关键字或使用Method::Signatures::Modifiers即可解决此问题。与 Method::Signatures::Modifiers 相比，我看到的性能损失约为 2-5 倍（5 倍主要针对我正在使用的一个特定类）。而且似乎主要是编译时间或者可能是第一次初始化，因为当计算时间较长时，它会低于 2x。
Method::Signatures::Modifiers有更好的错误，但是当您使用调试器时，您必须关闭此优化（它会变得混乱，因为它看不到这些方法，您可以在中亲自查看-MO=Deparse 输出）。摆脱 Perl 争论转移地狱可能是值得的。
MooseX::DeclareandMooseX::Method::Signaturesare working well but they can have really nasty penalty depending on what does your code do. This can be fixed by just not usingmethodkeyword or usingMethod::Signatures::Modifiers.Performance penalty I am seeing is around 2-5x compared to
Method::Signatures::Modifiers(5x being mostly for one specific class I was using). And it seems that it is mostly compile time or maybe first time initialization, because it is getting under 2x when the computation is longer.Method::Signatures::Modifiershas better errors but you have to turn this optimization off when you use debugger (it goes haywire because it does not see these methods, you can see for yourself in-MO=Deparseoutput).It may be worth it to get rid of Perl argument shifting hell.