Do you have an actual use case for these? Or are you just imagining things that might possibly potentially be cool in the future maybe?
Um, what? That was it, that was my actual use case, use ack in a program for the same reason I'd use ack from the commandline , to get a list of files, or get a list of lines, or get a list of files and lines
only the iterator portion inspired by File::Find::Rule/Iterator::Files iteration interfaces is a might-as-well-implement-it-if-you-re-implementing-it-thought-of-it-now
The most important thing ack does that I can't do as trivially /easily myself already is all the filetype stuff
sure it's easy to give find( qr/\.(pm|pl|pod|t)$/i ) for perl , i know perl, but what about --ruby? and others ...
that's the killer feature ack has over grep, is simple/easy filetype/mimetype ... recognition with --perl --cpp ...
Sure, I could cobble something together using MIME::Type/mmagic... and file::find,
or I could shell-out to ack , which i've done , but then switched to file::find::Rule (shell is bleh)
You do realize that ack's filetype detection is A) nothing at all related to MIME::Type, and B) entirely based on user-created rules, right? ack ships with sensible defaults, but they're still user-defined rules.
If it's File::Find that you are fighting with, then why not take a look at File::Next, which is the underlying file-finding engine that ack uses?
When I asked about use cases, I should have been more clear: Have you actually written code where you shell out to ack to get filenames? Or had it give you search results?
What did you do with the search results then?