In Should We Include a Better Alternative to File-Find in the perl5 Core?, Shlomi suggests that just as CPANPLUS and Module::Build entered 5.10 as alternatives to CPAN and MakeMaker, it's worth considering adding an alternative to File::Find to the core.
I understand the desire, but that kind of thinking digs the hole deeper.
The Perl 6 core will contain only those libraries absolutely necessary to download, configure, build, test, and install other libraries. (That trick seems to work for free operating systems.)
In a better world, Perl 5 would do the same and shed a few megabytes, as well as all of the crazy baggage required to make dual-lived modules work. Creating Bundle::BloatMeHarder is trivial.
The one corner case I can't quite figure out is how such a scheme would increase the likelihood of dropping support for ancient versions of Perl, such as everything older than Perl 5.8.8.
I don't like File::Find::Rule at all, and everyone seems to have their favorite. At least I know I can make File::Find work reliably, even if it's clunky.
Why not create a wrapper module with better interface? That way you can keep it...and make it "better". Seems it isn't going away anyway.
Re:Keep File::Find...and
chromatic on 2009-02-18T08:40:43
Why not create a wrapper module with better interface?
For the same reason that Buffy Summers stakes vampires instead of giving them nice suits and $50 and sending them to charm school. Sometimes dangerous things are better off really dead.
At some point, you have to pay off the technical debt of backwards compatibility, at least if you have any hope of maintaining the project.
Re:Keep File::Find...and
drhyde on 2009-02-18T11:31:55
Can you come up with an actual reason instead of a poor analogy? Unlike fictional vampires, File::Find only harms those who choose to be harmed by using it directly. File::Find is more like a big fried breakfast with all that nasty fat and EVIL meat, and we have a technical term for people who say breakfast should be banned. That term is "idiot".Re:Keep File::Find...and
Shlomi Fish on 2009-02-18T18:52:25
Inspired by your post, I'd like to make a post to my technical journal (with the "perl" tag which should put it on Perlsphere), called "The Case for File-Find-Object". I'll give several use cases for tasks you can achieve with F-F-O that you cannot achieve easily with File::Find.
Here's a sneak preview:
1. Aborting from scanning a huge directory tree once you found the single or a few desired result. (See also this question on stackoverflow). Very painful and hacky with File::Find, but trivial with F-F-O's iterative interface.
2. Implementing something like diff -r (recursive diff) in Perl. In F-F-O you can instantiate two different traversers to the two directories and gradually iterate one file at a time. Using File::Find you'll need to collect all the results from the two directory structures into two arrays, sort them both, and then walk over the arrays.
I don't have any ideas for more use cases, but I'm always open to suggestions. And using File-Find-Object all of your code can be written using method calls instead of setting global variables and other brain-damage.
Re:Keep File::Find...and
chromatic on 2009-02-18T19:17:25
Unlike fictional vampires, File::Find only harms those who choose to be harmed by using it directly.
... such as Perl novices who quite logically believe "It's in the core, so it must be good!"
Consider Matt's Script Archive. How many people cut and pasted that code without realizing that it was buggy and insecure?
Which is easier, correcting all of the existing code and tutorials and documentation to add a disclaimer that File::Find is difficult to use and that there are better alternatives, or formally deprecating File::Find altogether in a new version of Perl?
(Assume that Perl 5 has a regular release schedule and thus can support a formal deprecation policy.)
