Log in

Should We Include a Better Alternative to File-Find in the perl5 Core? - Shlomif's Technical Posts Community [entries|archive|friends|userinfo]
Shlomif's Technical Posts Community

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Links:| Shlomi Fish's Homepage Main Journal Homesite Blog Planet Linux-IL Amir Aharoni in Unicode open dot dot dot ]

Should We Include a Better Alternative to File-Find in the perl5 Core? [Feb. 16th, 2009|11:28 pm]
Shlomif's Technical Posts Community


[Tags|, , , , , , , , , , , , ]
[Current Location |Home]
[Current Music |Brad Sucks - Dropping Out of School]

chromatic asked for some link/follow-ups love to his "Modern Perl Books" blog, so here's a post inspired by one of his Modern Perl posts where he complains about how inane the File-Find interface is. I personally share chromatic's sentiments about File-Find, and have for many years. After posting to perl5-porters about its shortcomings, it was agreed that fixing them in File-Find may hurt its performance, and so was not acceptable without forking the code or rewriting it. At the end of the thread, I mentioned that I found File-Find-Object on CPAN, and that I intend to contribute to it and improve it. That's what I did, and I eventually took over its maintenance from the originator.

File-Find-Object solves all the major shortcomings of File-Find that I'm aware of. But this post is not specifically about File-Find-Object. If someone will come up with a better alternative to File-Find than File-Find-Object is, then I'll support the new code.

The point is that I think that, as a statement of intent, and of general disgust from File::Find, a different module with a better interface and a saner and more modern philosophy should be shipped as part of the perl 5 core. It's not the first time that a core module in perl 5 was "complemented" with a better alternative: CPANPLUS.pm was added to the core in addition to CPAN.pm , Module::Build was added as an alternative to ExtUtils::MakeMaker, and recently Test::Harness was augmented with TAP::Parser/TAP::Harness/Test::Harness-3 . I don't see why File::Find should be any different considering the fact it has several philosophical usability problems which cannot be easily overcome (it cannot be instantiated, cannot be easily interrupted in the middle, and does not have an iterative interface).

I don't suggest we change the File::Find API. That will wreck havoc. But I think we should include another module and put a big and visible notice at the beginning of File::Find saying "File::Find is deprecated and should no longer be used! Use $better_file_find , that ships with perl as of perl-5.12.0 or available from CPAN for earlier versions, instead."

What do you think?