是否“可以”？用 Moose 包装标准 Perl 模块？
许多标准模块都直接使用 Perl ——问题是这些人没有使用 Moosey 的东西，所以我发现自己用 Moose 包装它们，或者为了方便在更大的库中重新发明一些简单的函数。
我想知道使用 Moose 的开发人员如何整合其他非 Moose 库是否有任何通用方法。
作为 Perl 和 Moose 的新手，我想更好地了解 Moose 在这种情况下是如何使用的，或者通常更喜欢使用 Moose 与 Perl 甚至 MooseX，或其他一些包，或者它是否是任意的。
似乎有不同的思想流派，但 Perl 和它一样古老——有太多相互冲突的来源，所以很难找到一致的事实。我不知道该相信什么！
有人有关于 Perl 的“现代”用法的明确来源吗？了解我只使用 Perl 一个月，所以我对这个社区很陌生。
更新
我不想以他们可能不欣赏的方式谈论他们喜欢的库来伤害任何人的感情，所以我删除了我对某些库的旁注，我曾经重新关注这个问题手。
感谢您的指导！
Many standard modules are all using straight up perl -- problem is these guys arent using Moosey stuff, so I catch myself wrapping them with Moose or reinventing some simple functions in bigger libraries for convenience.
I wondered if there was any general approach to how developers using Moose incorporate other libraries that are non-Moose.
Being new to Perl and Moose I'd like to have a better understanding of how Moose is used in situations like this, or when it is generally preferred to use Moose vs Perl or even MooseX, or some other package, or whether its arbitrary.
Seems like there are different schools of thought, but Perl being as old as it is -- there are too many conflicting sources, so it's hard to navigate to a consistent truth. I'm not sure what to believe!
Anyone have a definitive source they turn to for "modern" usage of perl? Understand I've only been using perl for a month so I'm green to this community.
Updated
I don't want to hurt anybody's feelings by talking about libraries they love in a way they may not appreciate, so I've removed my side commentary about certain libraries Ive used to refocus on the question at hand.
Thanks for your guidance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
虽然我不知道别人在做什么，但我非常不愿意给自己增加额外的工作。我不认为有任何一般需要 Moosify 一堆已经可以工作的模块。
如果您想从非 Moose 模块继承，请查看 MooseX::NonMoose。
如果 CGI.pm 中的 HTML 生成问题困扰您，您可以使用 CGI::Simple。
While I do not know what others do, I would be very reluctant to create myself extra work. I do not see any general need to Moosify a bunch of modules that already work.
If you want to inherit from non-Moose modules, take a look at MooseX::NonMoose.
If the HTML generation cruft in CGI.pm bothers you, you can use CGI::Simple.
关于重新发明 CGI
CGI 是一个经过彻底尝试和测试的库，如果需要改进，您可以构建一个扩展，或者贡献/联系维护人员。您必须记住，模块的好坏取决于它们的记录（可靠性）和维护。许多人创建了不错的模块，但没有继续维护它，因此他们陷入了默默无闻。
CGI 本身就是一艘船，如果您认为开销很大，您可以使用 CGI::Simple 或 CGI::Minimal。 CGI.pm 不仅仅是解析查询字符串，它还具有 cookie 管理（会话）、HTML 生成和其他有用的功能。
其他人对 CGI.pm 的开销有一些批评，但这就是他们开发 FastCGI 的原因，它正在修改服务器以使用脚本的持久状态，从而加载一次开销，而不是在每次页面加载时加载。
您可以创建另一个（甚至更好）的版本，但何必呢？许多人可能会告诉你，你不应该重新发明轮子，这是有充分理由的。 CGI 已经存在了近 20 年，有如此多的用户对其进行测试、发现漏洞并修补漏洞；然而，我从来不喜欢说“你不应该做某事”。如果你认为某件事可以做得更好，那就让它变得更好。正是由于这个原因，如今存在许多操作系统，如果您还需要另外 5% 的功能，为什么还要满足于满足您 95% 的需求呢？但我也说，权衡您的成本与收益，并确定您是否愿意将时间投入到此上，或者是否还有其他问题尚未解决，这可能需要一点时间更多的人力。要获得成功，您需要对其进行彻底测试，并且很可能需要创建其他人想要的东西，并且（在这一点上）没有太多理由激励 CGI 用户切换。
关于现代 Perl
我认为“现代 Perl”是一个矛盾的说法。我会开玩笑地称其为现代 Perl； Ruby 或 Python。
这并不是说 Perl 没有用，因为它确实有用，但它已经存在很长时间了。虽然它在各个版本之间都有很大的变化，但最流行的 Perl5 并没有发生太大的变化。请注意，我对更改的定义不是添加到语言中（新的运算符和功能），而是弃用/替换旧功能或更改现有功能的行为（例如
for/foreach循环）。注意：Perl6 可以被认为是现代 Perl（并且确实有许多重大变化），但它没有被广泛采用，并且应该在很多年前发布（它是编程语言中的 Duke Nukem 4 Ever）。 >
关于XS
我没有做过太多模块编程，但是如果没记错的话， XS 是Perl 和 C 之间的接口，我认为它允许您编译 Perl 模块以加快执行速度。考虑 PostgreSQL DBI 模块。有一个DBD::PgPP ，这是一个与 Postgres 交互的纯 Perl 模块，但还有DBD::Pg，我认为使用 C 编译一些代码并利用一些其他操作系统实用程序。编译模块的优点是加载和执行速度更快（其中也可能有一些更好的资源管理）。
About Reinventing CGI
CGI is a library which has been thoroughly tried and tested and if it needs improvement, you could build an extension, or contribute/contact the maintainers. You have to remember that modules are only as good as their track record (reliability) and their upkeep. Many people created decent modules, but didn't continue maintaining it, so they sort of fell to obscurity.
CGI is a boat all of its own, which if you think there's a lot of overhead, you could use CGI::Simple or CGI::Minimal. CGI.pm does more than parse querystrings, it also has cookie management (sessions), HTML generation, and other useful functions.
Others have had some criticisms of the overhead with CGI.pm, but that's why they developed FastCGI, which is modifying the server to use a persistent state of the script, thus loading the overhead once, rather than on every page load.
It is possible for you to create another (even better) version, but why bother? Many people may probably tell you, you shouldn't reinvent the wheel, with good reason. CGI has been around for almost 2 decades, with so many users testing it, finding holes, and having patched the holes; however, I'm never a big fan of saying "you shouldn't do something." If you think something could be better, make it better. There are many OSes that exist today just because of that reason, why settle for something that does 95% of what you need, if you need that other 5% too? But I also say, weigh your costs vs. benefits and determine if you want to devote your time to this, or if maybe there's another problem out there that has yet to be solved, that could use a little more manpower. To have something successful, you're going to need to test it thoroughly, and will most likely need to create something that other people would want and (at this point) there isn't much of a reason for CGI-users to be motivated to switch.
About Modern Perl
I think "modern Perl" is an oxymoron. I would jokingly call modern Perl; Ruby or Python.
That isn't to say that Perl isn't useful, because it is, but it's been around a long time. While it has had its significant share of changes from version to version, the most popular, Perl5, hasn't changed all that much; mind you, my definition of change is not adding to the language (new operators and functionality), but deprecating/replacing old features or changing the behavior of existing ones (like
for/foreachloops).Note: Perl6 could be considered modern perl (and does have many significant changes), but it's not widely adopted and was supposed to be released many many years ago (it's the Duke Nukem 4 Ever of programming languages).
About XS
I haven't done much module programming, but if memory serves correct, XS is the interface between Perl and C, which I think allows you to compile your perl modules for faster execution. Consider the PostgreSQL DBI module. There's a DBD::PgPP, which is a pure perl module to interface with Postgres, but there's also DBD::Pg, which I think compiles some of the code using C and takes advantage of some other OS utilities. Compiled modules have the benefit of faster load and execution (there may be some better resource management in there too).