这更像是一个用例类型的问题...但是也足够通用，可以更广泛地应用：
简而言之，我正在研究一个或多或少是命令行包装器的模块； OO自然。无需过多讨论（除非有人想要），系统并没有疯狂的复杂性，但是在此框架中拥有三个或四个对象确实很自然。最后，这是我将要发布的开源内容，而不是由同一家公司的几个开发人员进行开发的模块。
首先，我使用Class :: Std实现了OO，因为Perl最佳实践（Conway，2005年）对为何使用由内而外的对象提出了很好的论据。完全控制访问哪些属性，等等，适当的封装等。他的设计也出奇的简单和聪明。
我喜欢它，但是随后发现没有人真正使用它。实际上，Conway自己似乎再也不建议这样做了？
所以我搬到了每个人的最爱，穆斯。它很容易使用，尽管对于我想做的事情而言，功能过于强大。最大的主要缺点是：大量的模块依赖项迫使我模块的用户全部下载它们。一个小的缺点是，它具有比我真正需要的更多的功能。
有什么建议？通过强迫他们使用可能已过时的模块给其他开发人员带来不便，还是迫使该模块的每个用户下载Moose及其所有依赖项？
是否有一个流行的适当的Perl OO框架的第三种选择，而这两者都不是？
最佳答案
公平地说，在Perl世界中看到的几乎所有有趣的事物都将Moose作为依赖项，我认为这对其他“ Perl资深开发人员”来说不算什么。
在我们讲话时，他们很可能已经安装了它！
编辑：一些统计信息：
Moose目前在“最依赖”模块列表Aliases top 100上排名第65位，并且有超过1637个包装依赖于它。那几乎和Time::HiRes之类的东西一样多，比DBI之类的东西还多，而且我认为您不太可能根据这些内容来质疑吗？