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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Interface (Score:2, Informative)
Yeah, I thought about doing a "nice" version of File::Find myself. I wanted to tie in a few things as well - the ability to get structured data as well as lists from it, and to cache data.
I'm not sure I like the stream-y interface you've got here - powerful, but violates the KISS principle which makes File::Find such a pain in the arse to use at the moment. I'd pictured more of a hash-based interface, but I hadn't thought of options so much (but I guess they could be done either by regexps or arrays).
myRe:Interface (Score:1)
I'd like to see something like this:
my @files = find('/tmp', { maxdepth => 10, mindepth => 5, name => qr/\.*\.c$/ });(Which I btw already have working in a small example I hacked together.) I really like your idea of using arrays for alternation, but how do you decide wheter to AND or OR? (AND doesn't make much sense in your example though).
Instead of returning the files I'd also consider an 'exec' like option that took a s
Re:Interface (Score:1)
Warning: hashes found not to have a predictable order. Evaluating the rules in a known order can have a huge effect on efficiency. Please look at rafael's "Good example for 'or'" comment, if the exec happened first you'd really feel a hit from it just shortcutting that happens at
name('*.pl').(Which I btw already have working in a small example I hacked together.)
Please, don't let me stop you releasing your code to CPAN. Some choice in this area is good, certainly considering the current state where people just complain about the current state of affaris without writing an alternative.
For fun, mine's here [unixbeard.net], note that it still needs a buttload of work on the documentation. Later today I was planning on added some code to make this work
But maybe find_luddite isn't the best name :)
I really like your idea of using arrays for alternation, but how do you decide wheter to AND or OR? (AND doesn't make much sense in your example though).
AND is the default.
Means they have to be files, AND they have to have names that match *foo*.
Instead of returning the files I'd also consider an 'exec' like option that took a sub ref or function and just passed the filename to it as the first argument.
Check. Well actually I pass the filename, the directory, and the full path, but that's because you never know what'll really be useful.
That is about all I'd need from a Perl find.
Bzzt! About all I need from a find interface is File::Find. This is a deeply bogus argument, and it's left us where we are since the dawn of time.
In writing this code I'm trying to anticipate what other users will want. You're one of them, but you're not the only one otherwise I'd not even have thought about making the code useable as an iterator, so you'll be able to write.
Warning: routines not really called
find_iterativelyanditerate. They don't have names right now.Currently the code is a wrapper around File::Find, so the iterator behavior is faked, but if I ever get brave enough to implement all the cross-platform stuff for myself then that'll be a proper iterator. And then there will be rejoicing in the streets. Oh yes.
Reply to This
Parent
Re:Interface (Score:1)