I have never used File::Find, so I may be incorrect, but a brief reading through the POD of File::Find::Closures revealed a potential typo. In the synopsis, you have this:

my( $list_reporter, $wanted ) = find_by_name( qw(README) );
[download]

Each factory returns two closures. The first one is for find(), and the second one is the reporter.

Drats. The example is out of date, and I will fix that in the next upload.
--
brian d foy <bdfoy@cpan.org>

How did I use Filter Chaining and still get reuse of my filters? My C++ module kept returning FilterCollection objects with each cascading application of a filter until the method was terminated with an apply statement.

Thus I could build filters like:

FilterCollection* fc = new FilterCollection(rootObj)->isType("foo")->h
+asProperty("bar",5150);
FilterCollection* fc2 = fc->hasProperty("baz",812)->apply();
for(int i=0; i< fc2.size(); i++) {
   // do something with fc2.elementAt(i)
}
[download]

Now that isn't Perl, but you can see how Merlyn's module can be used to support reuse, while still keeping the totally gnarly and radical filter chaining idiom. If you needed that, I'd rather see an optional mode on Merlyn's module, or File::Finder2 or something, rather than a procedural interface that discards this killer idiom -- if reuse is what you are after, maybe the wheel doesn't need reinvention. I assumed that by reuse you meant efficient reuse of the filter results, as if you just wanted extra file checking methods inside of Merlyn's filter chain you could have added them.

(Long optional OT aside: The meta question here is -- was this module neccessary for CPAN, especially when it is unfinished? It should have probably stayed on a developer machine. CPAN is kinda crowded and confusing as it is, I don't like to see "alpha" modules up there as that is just more to sort through, especially when the alpha module could have contributed to another project. As for why this module was created when close alternatives exist, this is a FOSS problem -- forking -- but it's a problem which Linux and GPL apps tend to maintain pretty well (patches contribute upstream, etc). CPAN, however, doesn't resist forking as well...so we end up with a lot of modules that do the same thing. Sometimes it's good, but it's very rough on a user trying to find a module. This meta-question is one that we have not solved ... and probably won't ... but a little bit of education and end-user perspective may help ebb the tide of CPAN bloat. These could have been made File::Finder compatible too -- such that people could have the best of both worlds. Why was that decision made?)

Disclaimer, actually in my implementation, each filter does contain references to the data that successfully passed through the filter for purposes of passing them to the next filter, however the filters are reusable -- you just pay for them when you build each progression. If you want rules though, you can easily see how this could be used to build a cascading engine, where the apply() works the original list down each stage of filters and does not generate anything until apply() is called. You could also allow for inclusion of apply in the middle of a chain, selectively chosing when you do or do not evaluate the filter chain, e.g. FilterCollection->hasProperty("grok",2)->apply() would be interatable (sp?) but you could then take the resultant FilterCollection from that apply call and either reset() it or just take on more calls which would also add to the chain. Perhaps taking an additional progression onto an already applied chain would automatically reset the filter.

Dude, I love Computer Science...

I also provide an "all" method which returns all the files as a list, which can pe post-processed by the likes of map and grep.