Ricardo SIGNES wrote:
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39]

And then still people make more of the same. Take Getopt::Long. A perfect and
very functional module. Full of features, matured, and actively maintained.
Now go look at CPAN, and see how many people either do not like it or find
other reasons to write their own.

The problems arise when authors of big modules start prefering non-core
versions of good core modules. IMHO something like that should give you a
(very) negative score on CPANTS.


Could you elaborate on this?  As stated, it seems pretty ludicrous to me.  It
reads like this:

  You should not use module B that is like module A, if A is in the core
  distribution.  This is true regardless of the fact that B may be better
  optimized for your current needs, planned needs, programming style.

This can be further distilled to:

  There's more than one way to do it, but most of them will get you dirty
  looks.

This can vary of course, for example using Params::Util might be ok instead of Params::Validate.

And I state that as a fact, because I wrote Params::Util and... well... so there.

But there's very little point in using Exporter::Lite because 100 other modules use Exporter in any given program.

So even though Exporter::Lite is lite'r than Exporter, the use of Exporter is zero, while Exporter::Lite means loading another module, and adds another dependency.

And because dependencies are recursive, you inherit it's baggage.

If one dep doesn't work on VMS, now your program doesn't.

And the more dependencies, especially if you are using more than one module that does the same thing just because of stylistic differences, then it means more problems.

It's not till you hit something like Ricardo's exporter, which does some very novel and interesting extra things, that you reach the threshold.

It's mostly the same, but if you need the extra parts, then it might be worth the extra dependency.

Adam K

Reply via email to