jdavidb (email not shown publicly) http://voiceofjohn.blogspot.com/ J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.
I far prefer File::Next's iterator approach, which is why I wrote it.:-) I find it makes more sense to just make a little filter callback rather than front-load all these rules like in F:F:R.
It's all adapted from MJD's iterators in Higher Order Perl. ack is based on it.
Well, you still need to take care of the bugs in RT [cpan.org] (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 [perl.org].
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 t
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).
Well, it not installing on Windows (due to http://rt.cpan.org/Public/Bug/Display.html?id=13993 [cpan.org]) 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.
I don't have a competing module to hype up, but I'm not sure exactly what is wrong with "hasn't been updated since 2006" - if it doesn't have any bugs and works with the latest versions of perl and the modules on which it depends then I can't see any reason which it should have been updated. Infact I would say this is a good thing - the author made a well designed, bug free module in the first place.
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.
Inspired by this discussion and the recent inter-blog discussion about File::Find I decided to unleash
File-Find-Object-Rule [cpan.org], 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 [berlios.de].)
File-Find-Object-Rule is a fork of File-Find-Rule that was adapted to use File-Find-Object [shlomifish.org] instead of File::Find. Read the link for why File-Find-Object is superior to File::Find. There are still some anac
While everybody's hyping up their own favourite File::Find [cpan.org] 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 [cpan.org], 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
The point is, push @files, $File::Find::name is 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
Use FIle::Next (Score:2)
--
xoa
Stable (Score:2)
Re: (Score:1)
Re: (Score:2)
Well, you still need to take care of the bugs in RT [cpan.org] (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 [perl.org].
Re: (Score:1)
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 t
Re: (Score:2)
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).
Consider File::Finder (Score:2)
Re: (Score:1)
Well, it not installing on Windows (due to http://rt.cpan.org/Public/Bug/Display.html?id=13993 [cpan.org]) 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.
Stability (Score:2)
Re: (Score:2)
http://rt.cpan.org/Public/Dist/Display.html?Name=File-Find-Rule [cpan.org]
may we all live in *un*interesting times (Score:2)
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.
Just Works (Score:2)
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.
FFR is still the best searching module (Score:1)
... mainly because of the complexity of plugins you can write for it.
File::Find::Rule::Perl [cpan.org]
File::Find::Rule::PPI [cpan.org]
File::Find::Rule::VCS [cpan.org]
(And soon)
File::Find::Rule::NoIndex
File-Find-Object-Rule (Score:2)
Inspired by this discussion and the recent inter-blog discussion about File::Find I decided to unleash File-Find-Object-Rule [cpan.org], 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 [berlios.de].)
File-Find-Object-Rule is a fork of File-Find-Rule that was adapted to use File-Find-Object [shlomifish.org] instead of File::Find. Read the link for why File-Find-Object is superior to File::Find. There are still some anac
File::Find (Score:2)
While everybody's hyping up their own favourite File::Find [cpan.org] 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 [cpan.org], 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
Re: (Score:1)
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