用 Moose 包装标准 Perl 模块是否“可以”？

Question

许多标准模块都直接使用 perl —— 问题是这些人没有使用 Moosey 的东西，所以我发现自己用 Moose 包装它们或者为了方便起见在更大的库中重新发明一些简单的函数。

我想知道是否有任何通用方法可以让使用 Moose 的开发人员合并其他非 Moose 库。

对 Perl 和 Moose 不熟悉我想更好地了解 Moose 在这种情况下是如何使用的，或者什么时候通常更喜欢使用 Moose 与 Perl 甚至 MooseX 或其他软件包，或者是否它的任意性。

似乎有不同的思想流派，但 Perl 已经很老了——有太多相互冲突的来源，所以很难找到一致的真理。我不知道该相信什么！

任何人都有明确的来源来“现代”使用 perl 吗？了解我只使用 perl 一个月，所以我对这个社区很陌生。

更新

我不想以一种他们可能不欣赏的方式谈论他们喜欢的图书馆来伤害任何人的感情，所以我删除了我对某些图书馆的旁注，我过去常常重新关注手头的问题。

感谢您的指导！

Answer 1

虽然我不知道其他人在做什么，但我非常不愿意为自己创造额外的工作。我认为没有任何普遍需要 Moosify 一堆已经工作的模块。

如果您想从非 Moose 模块继承，请查看 MooseX::NonMoose。

如果CGI.pm 中的 HTML 生成问题困扰您，您可以使用 CGI::Simple。

Answer 2

关于重塑 CGI

---

CGI 是一个经过彻底尝试和测试的库，如果需要改进，您可以构建一个扩展，或贡献/联系维护者。您必须记住，模块的好坏取决于它们的跟踪记录（可靠性）和维护。许多人创建了不错的模块，但没有继续维护它，所以他们有点默默无闻。

CGI 本身就是一艘船，如果您认为开销很大，可以使用 CGI::Simple 或 @ 987654322@。 CGI.pm 不仅仅解析查询字符串，它还具有 cookie 管理（会话）、HTML 生成和其他有用的功能。

其他人对 CGI.pm 的开销提出了一些批评，但这就是他们开发 FastCGI 的原因，它正在修改服务器以使用脚本的持久状态，从而加载一次开销，而不是在每个页面上加载。

您可以创建另一个（甚至更好）的版本，但何苦呢？很多人可能会告诉你，你不应该重新发明轮子，这是有充分理由的。 CGI 已经存在了将近 2 年，有很多用户对其进行测试、发现漏洞并修补漏洞；然而，我从来都不喜欢说“你不应该做某事”。如果您认为某些事情可以做得更好，那就让它变得更好。正是因为这个原因，今天存在许多操作系统，如果你也需要另外 5% 的东西，为什么还要满足于你需要的 95% 的东西呢？但我还要说，权衡您的成本与收益，并确定您是否愿意为此投入时间，或者是否还有其他问题尚未解决，这可能需要一点时间更多的人力。要获得成功，您将需要对其进行彻底的测试，并且很可能需要创建其他人想要的东西，并且（此时）没有太多理由让 CGI 用户有动力换成。

关于现代 Perl

---

我认为“现代 Perl”是矛盾的。我会开玩笑地称现代 Perl；红宝石或 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 编译了一些代码并利用了其他一些操作系统实用程序。编译后的模块具有更快的加载和执行速度（其中可能还有更好的资源管理）。