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