I try to avoid such overkill when I'm just recursing down 2 directories and throwing the structure in a HoA.

You keep saying overkill. You said it about File::Find itself, and you say it here. I think its a bad argument. File::Find uses Carp, Exporter and Cwd either directly or indirectly. Exporter gets included with most modules, Cwd is pretty common and even still isnt that big, Carp is like Exporter, its almost always being used. (Just saying use warnings; brings it into existance. As for File::Find itself it isnt that large either. So I think your overkill argument is bogus. Especially when it allows you to write:

use File::Find;
my @files;
find {no_chdir =>1, wanted => sub{-d and return; push @files,$_ } },@r
+oots;
[download]

Putting the files into the desired data structure is left as an excercise for you. I might just say that I suspect File::Spec will come in useful.

The point here is that in trying to avoid overkill that doesn't exist you have wasted a bunch of time trying to partially reinvent a wheel. You seem to be more concerned with the startup time of your script (which is mostly determined by the OS and physical resource bottlenecks) and not the time it takes you to write the script. I bet you would have to run your program literally thousands of times before you will make up the lost time that you personally have suffered.

This comes down to premature optimisation. You are trying to a make a process faster when you have absolutely no evidence that that process is suffering performance problems. (You cant have this evidence as you havent written the script yet have you?) So you have comitted two golden gaffs, the first is to optimise prematurely, and the second is to badly reinvent a wheel to do so. This is hardly an efficient use of your time.

This is hardly an efficient use of your time.

That depends, I don't learn as much using a module :)

It also introduces lots of extra code that has to be audited and maintained. The execution time is a very minor concern. Your points are all valid, they're just not my approach.

Thanks for the reply :)

That depends, I don't learn as much using a module :)

Yes you do. You learn what wheels already exist and how to use them. This is useful when you have to do something quickly, when you need to do something correctly the first time (or with minimal hassle) or even possibly to get yourself a job. A potential employer for a Perl job would hardly be encouraged to hear that you were perfectly capable of writing a directory traversal (on your say so), but could not off the top of your head write an elementary File::Find statement (which they just might test you on.)

If you really want to learn then read the source code of the module in question. You will learn far more about directory traversal by reading the source code of File::Find than you ever will learn writing your own from scratch. Being part of the standard distro the code must run on every OS that perl runs on, this means it will be written to handle all sorts of cases that you are unlikely to know of.

Now don't get me wrong. Reinventing wheels can be an extremely educational process. But doing it without a thorough understanding of the existing wheel (and frankly in this context a wheel is not a great example IMO :-) doesn't make a lot of sense.

It also introduces lots of extra code that has to be audited and maintained.

Every single module involved is part of the standard distro. If you are worried about auditing and maintaining these modules modules then you should be equivelently worried about Perl itself. If these modules have issues then they will be fixed by the P5P team. For me I would be far far more worried about my handrolled creation going subtly wrong than anything that comes with the standard distro.

Anyway, just my $0.02


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}