Re^5: When should a wheel be reinvented

[etcshadow]

Interesting...

Honestly, I'd really rather not see yet another implementation of directory traversal in perl. What I think would be the ideal is to have just one implementation (let it stay File::Find, everyone already knows it!), but have that implementation be usable with each of these types of interface:

1. callbacks
2. declaratively (by that I mean: my @files = File::Find::find(...); or something similar)
3. iterator

Presently, File::Find provides 1, directly. File::Find::Rule and its ilk provide 2 (as a wrapper around File::Find... which is great, because that means no one has to replicate the directory traversal code for that). The thing that's missing is a good iterator interface, and, again, that can't be built as a wrapper around File::Find.

So of course, the best possible thing (in my opinion) would be if someone rewrote File::Find so that it (internally) had an iterator interface:

my $finder = File::Find->new($opts, @dirs);
while (my $file = $finder->next) {
   # do stuff
}

And then, finally, to change the old familiar File::Find::find(...) to be implemented as a simple wrapper around File::Find's iterator interface:

# simplified a lot, but basically
sub find {
    my ($opts, @dirs) = @_;
    $opts = wrap_wanted ($opts);
    my $wanted = $opts->{wanted};
    my $finder = File::Find->new($opts, @dirs);
    while (my $file = $finder->next) {
        local $_ = $file;
        local ... # etcetera
        &$wanted
    }
}

So you'd get:

• all the benefits of each type of interface
• the directory traversal written (and optimized and maintained, etc) only once
• nothing gets broken (all we've done is to refactor and to add new functionality)

Of course, I feel bad demanding this, without volunteering to do it, but honestly, it would create legal complications if I were to do so (I've got one of those contracts where my employer owns everything I do... at least for the moment, but I've been promised that that will change at least somewhat by the end of july). But I still think that the "most best" approach is clear enough that it's worth setting down (even if I'm not going to go off and implement it myself).