Front page | perl.perl5.porters |
Postings from February 2009
> In my blog post, I suggested that we ship an alternative > to File-Find in the perl 5 distribution or (alternatively) that we noticeably > refer the people who read the File::Find manual page to alternatives. > > Then chromatic said "That's not what I meant" and that he doesn't want us to > bloat the perl 5 core with non-essential modules. > > What do you think? IMHO: What should happen first is that the module should be finished and should be stable. Since October there were 8 releases, to me that indicates that it is either not finished or not stable (enough). (Finished in the sense that it should support everything File::Find does while leaving room for adding features without breaking the API) What is critical is that the following questions are asked: - Why do 'I' want it in the CORE? - Why would others want it in the CORE for others? - What is the advantage of it being in the CORE for 'me'? - What is the advantage of it being in the CORE for 'perl/p5p'? - What is the disadvantage of it being in the CORE for 'me'? - What is the disadvantage of it being in the CORE for 'perl/p5p'? - On what other modules does File::Find::Object depend? All of these need to be added to the CORE. (And all of these need to platform independent/very well tested since a failure in one of the tests will trigger a not ok during `make test` and that might end up in rt.perl.org/that might stop someone from installing a new version of perl since some tests failed) IMHO: Mentioning it in File::Find looks like a good idea. (You can even annotate the version that is currently on CPAN) Kind regards, BramThread Previous | Thread Next