Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday February 17, 2009
02:47 AM

On Alternatives

[ #38498 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    • 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 [modernperlbooks.com], at least if you have any hope of maintaining the project.

      • 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".
        • Inspired by your post, I'd like to make a post to my technical journal [livejournal.com] (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 [stackoverflow.com]). Very painful and hacky with File::Find, but trivial with F-F-O

        • 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 de