用Moose包装标准Perl模块是否“OK”?

时间:2011-10-14 22:42:39

标签: perl moose

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

我想知道是否有任何一般方法来解决使用Moose的开发人员如何合并非Moose的其他库。

成为Perl和Moose的新手我想更好地了解Moose如何在这种情况下使用,或者通常更喜欢使用Moose vs Perl甚至是MooseX,或其他一些软件包,或者是否它任意。

似乎有不同的思想流派,但Perl已经老了 - 有太多相互冲突的来源,所以很难导航到一致的事实。我不确定该相信什么!

任何人都有一个明确的来源,他们转向“现代”使用perl?明白我一直只使用perl一个月,所以我对这个社区都很环保。

更新

我不想通过以他们可能不欣赏的方式谈论他们喜爱的图书馆来伤害任何人的感受,所以我删除了我对用于重新关注手头问题的某些图书馆的评论。

感谢您的指导!

2 个答案:

答案 0 :(得分:13)

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

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

如果CGI.pm中的HTML生成困扰您,您可以使用CGI::Simple

答案 1 :(得分:0)


关于重塑CGI


CGI是一个经过彻底尝试和测试的库,如果需要改进,您可以构建扩展,或者贡献/联系维护者。你必须记住,模块只能跟踪他们的记录(可靠性)和维护。许多人创造了不错的模块,但没有继续维护它,所以他们有点晦涩难懂。

CGI本身就是一艘船,如果您认为有很多开销,可以使用 CGI::Simple CGI::Minimal 即可。 CGI.pm不仅解析查询字符串,它还具有cookie管理(会话),HTML生成和其他有用的功能。

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

您可以创建另一个(甚至更好的)版本,但为什么要这么麻烦?许多人可能会告诉你,你不应该有充分理由重新发明轮子。 CGI已经存在了近20年,有很多用户在测试它,找到漏洞并修补漏洞;但是,我从来不会说“你不应该做点什么”。如果您认为某些事情会更好,那就让它变得更好。今天有许多操作系统只是因为这个原因,为什么能满足你所​​需要的95%,如果你还需要其他5%呢?但我也说,权衡你的成本与收益并确定你是否想把时间花在这上面,或者如果还有另外一个问题尚未解决,可能会使用一点更多的人力。为了获得成功,你需要彻底测试它,并且很可能需要创建其他人想要的东西,并且(此时)CGI用户没有太多理由被激励换成。


关于Modern Perl


我认为“现代Perl ”是矛盾的。我会开玩笑地称现代Perl; Ruby或Python。

这并不是说Perl没有用,因为它是,但它已经存在了很长时间。虽然它在版本之间有很大的变化,但最受欢迎的Perl5并没有发生太大的变化。请注意,我对变更的定义不是添加到语言(新的运算符和功能),而是弃用/替换旧功能或更改现有功能(如for / foreach循环)。< / p>

注意:Perl6可以被认为是现代perl(并且确实有许多重大变化),但它并没有被广泛采用,并且应该在许多年前发布(它是Duke Nukem 4 Ever of programming languages)。


关于XS


我没有做太多的模块编程,但是如果内存服务正确,XS是Perl和C之间的接口,我认为这允许你编译你的perl模块以加快执行速度。考虑PostgreSQL DBI模块。有一个 DBD::PgPP ,这是一个与Postgres交互的纯perl模块,但也有 DBD::Pg ,我认为使用C编译一些代码并利用其他一些OS实用程序。编译模块具有更快加载和执行的好处(也可能有更好的资源管理)。