What happened to File::Find::Rule? It apparently hasn't been updated since 2006. Once upon a time, it was the hottest module on CPAN.
Is it still a good idea to use this instead of File::Find/find2perl? Have I got the right module?
Re:Stable
richardc on 2009-02-17T09:48:34
Perfect might be a step too far, but as nobody's been screaming out at me that it's become broken, I'm going to have to go with 'it's done'.Re:Stable
Shlomi Fish on 2009-02-18T16:17:54
Well, you still need to take care of the bugs in RT (i.e: fix them or close them) or people may conclude, like J. David did., that F-F-R is abandoned. While you're in the neighbourhood, you may wish to deal with the Kwalitee problems.
Re:Stable
richardc on 2009-02-18T16:35:11
Hm, see I thought my positions on rt.cpan.org and Kwalitee were known at this point. I don't play either game.I deal with bugs that are mailed to me using the contact details in the AUTHOR block. If I want to use an rt queue then I can point people at it in the documentation, but you can see I haven't. That one automatically exists doesn't make it any more appealing to me, though I am grateful that the facility exists for people who do find it useful.
As to Kwalitee, I don't have the time in the day to game that system. I also don't feel that it has any direct effect on the fitness of the code, but that's a different argument.
I'm trying to be an active module author here, but when I have to cruise comments on blog posts to find out that people want me to change my code, something somewhere broke.
Re:Stable
Shlomi Fish on 2009-02-18T18:17:29
The CPANTS kwalitee is not very important, I just mentioned it in the same breath. However, if you don't want people to use rt.cpan.org, then you can use a META.yml field to point them to the right URL for the correct bug tracker. (See Ack's META.yml for an example). This URL may as well be a page on your homepage (or on a wiki) that says "Email me your bugs.". And you should close the bugs there with a nice comment saying "Please email them to me". (After you've done the META.yml change).
Re:Consider File::Finder
jplindstrom on 2009-02-17T17:16:17
Well, it not installing on Windows (due to http://rt.cpan.org/Public/Bug/Display.html?id=13993) is a blocker for me (even if I'm developing on a Unix) when there are perfectly fine options that are cross platform and won't cause problems for anyone else.
Re:Stability
djberg96 on 2009-02-17T18:38:15
I see 5 open bugs and 1 feature request. One of the bugs is 2 years old.http://rt.cpan.org/Public/Dist/Display.html?Name=File-Find-Rule
It apparently hasn't been updated since 2006.
Wasn't that a comment made of one of MJD's modules too? Maybe not for that particular year. But it too was about a module that works nicely, doesn't need feature creep, or new an unexpected surprises.
I like to turn "change is inevitable, progress is not" around, and think about the amount of progress any particular change gives. To me it implies that not all change is worth it.
I use F::F::R all the time. Please don't fall into the trap of assuming that just because it hasn't been updated in a couple of years, it should be avoided.
Try it out. Let us know how it worked out for you.
... mainly because of the complexity of plugins you can write for it.
(And soon)
File::Find::Rule::NoIndex
Inspired by this discussion and the recent inter-blog discussion about File::Find I decided to unleash File-Find-Object-Rule, which I've been working on for some time, to the CPAN today after a small amount of cleanup. (I hope the link works by the time you read it, if not see the svn trunk on Berlios.)
File-Find-Object-Rule is a fork of File-Find-Rule that was adapted to use File-Find-Object instead of File::Find. Read the link for why File-Find-Object is superior to File::Find. There are still some anachronisms in the first version I released (0.0100), but I hope to fix them soonish.
While everybody's hyping up their own favourite File::Find replacement, I just want to chime in and say that, for a lot of the replacement modules, I just like File::Find better. In particular, File::find::Rule, which I find just incomprehensible, and horrible.
I wonder if many of the "problems" people see for File::Find are actually problems. So it uses global variables as fake parameters... but they're dynamically limited in scope to (the immediate surroundings of) the callback sub. So I don't mind ist so much. The situation is actually very much alike to the keyword this in plenty of OO languages. Besides, File::Next does the same.
But you do have to do it the proper way: use an anonymous sub, not a reference to a global function. That way, you end up with a closure, instead of something that depends on global variables (not File::Find's own global variables, but yours).
Do
use Cwd;
sub traverse {
my @files;
find sub {
push @files, $File::Find::name if/.txt$/ and -f;
}, cwd;
return @files;
}
Not
use Cwd;
sub wanted {
push @files, $File::Find::name if/.txt$/ and -f;
}
@files = ();
find \&wanted, cwd;
Re:File::Find
Aristotle on 2009-02-23T10:41:09
The point is,
push @files, $File::Find::nameis what everyone does. So at best it’s unnecessary noise and the module should do that automatically.However, the reason everyone does that is because performing complex work from within a callback is a pain. State machines are no fun to write. An iterator interface is much nicer to work with when you have something complex to do, and just as easy to use when you really just want to collect the file names. It’s much friendlier to use in programs that run code out of an event loop, too (goes back to not having to write a state machine).
