On Sun, Feb 15, 2009 at 10:04 AM, Dan Dascalescu <[email protected]> wrote: > > I think I can agree with that. What I'm saying is that there's simply > too much useless choice. Random example: > > Data::Dumper > vs. > Data::Dump. > > I've just discovered Data::Dump but it appears to beat the crap out of > Data::Dumper. Yet does it say anywhere "Hey, if you're getting started > with Perl and need to dump variables, use Data::Dump, and don't waste > your time investigating other modules"? If I were the author of > Data::Dumper, I'd somehow retire the module, or plaster a note in the > POD redirecting people to Data::Dump. Imagine a programmer new to Perl > picks up an example that uses Data::Dumper. Will they find out about > Data::Dump? No.
There is also: http://search.cpan.org/~jmcnamara/Data-Dumper-Perltidy-0.01/lib/Data/Dumper/Perltidy.pm And frankly I think this naming convention is the way to go - this is much better findable than Data::Dump. And there is also Data::Dumper::HTML, that just recently I found very useful for debugging in web context. And to complicate the things - I cannot say for sure that this is the reason, but it is quite probable that Data::Dumper would have much better interface now if it was not in the Core. Modules that get into the Core generally get frozen and stop evolving because too many things rely on them. This is a complex matter and I lean towards the 'steady release cycles plus rigorous deprecating' proposed by chromatic in his recent Modern Perl blog notes (http://www.modernperlbooks.com/mt/). Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
