Re: File::Find considered hard?

For my own part, I will say that:

Passing subrefs as a way of delegating authority is cool, and I don't think it's a bad thing, when necessary. The downsides to it are that it is hard for people to understand if they are not used to the concept, and it is not a familiar idiom used in simple things in perl. (consider that getting all files in a directory tree is the sort of thing that a perl user might want to do significantly sooner in his/her perl career than writing a socket server).
The second issue (with which I've become intimately familiar) is that its interface does not accomodate being hidden beneath any kind of iterative interface... which makes it crappy for code-reuse. Say you're working on something which needs to iterate through all files in a directory, recursively, but it, itself, get's called in a sort of $obj->doNextFile() manner. The fact that File::Find cannot be wrapped in any way to provide the underpinnings for such an interface just sucks eggs. The only way that you can do this is if, on the first call to doNextFile, you call File::Find to generate you a list of all files, and store that as state within your object. If you're working over a very large set of files, this is just stupidly wasteful of space, and causes a huge penalty in fire-up time (what if you might want to bail out early? well you still had to construct a list of every file before you could even start).

Anyway, that's my $.02 on why the interface to File::Find is rotten. It's really the sort of module that you would prefer if newbs started using really early on, and currying function calls is the sort of thing that someone new to perl, and maybe just trying to hack together a few simple systems admin scripts, doesn't want to and should have to deal with. Also, it just sucks for code-reuse... I'm still on the knife edge of reimplementing File::Find's features for a project I'm working on, because I just don't want to have to start off by traversing the entire @#$%ing directory tree and storing it in a huge array.

------------
:Wq
Not an editor command: Wq
[download]

Comment on Re: File::Find considered hard? Select or Download Code

Replies are listed 'Best First'.
Re: Re: File::Find considered hard? by Jenda (Abbot) on Mar 16, 2004 at 20:36 UTC
I guess you are right it would be best if File::Find supported both types of interfaces, functional and iterative. There is no currying going on in here though. The find() is a higher order function, but it is not curried. If it was it would allow you to pass it just the wanted() function and get a function "find_and_do_something()": `my $delete_tmp = find(sub {unlink($_) if -f and /\.tmp$/i}); ... $delete_tmp->($one_directory); ... $delete_tmp->($other_directory); ..` [download] Jenda Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Rick Osborne Edit by castaway: Closed small tag in signature	[reply] [d/l]
Re: Re: Re: File::Find considered hard? by etcshadow (Priest) on Mar 16, 2004 at 20:58 UTC
The find() is a higher order function, but it is not curried. Right... I meant that the "wanted" function is (at least frequently) curried, or at least a closure. `------------ :Wq Not an editor command: Wq` [download]	[reply] [d/l]