You're probably right. Re-rolling a solution is probably a good idea. Especially since the module is a core module...that probably means it doesn't work that well. By your reasoning, we should eschew any module that we didn't write ourselves. Best of luck in that endeavor.
The only easy day was yesterday
Re^2: File::Temp randomness when forking
Replies are listed 'Best First'.
(Updated with improvements to example) No module works at all in an absolute sense. That is to say, provided you understand that to work means to meet requirements and since there are an infinite number of requirements, confining your thinking to a finite solution set for all time makes sure that your methods will fail most of the time, core module or not. The same is true of File::Find, also a core module - not all find requirements originating from actual business will match it as nicely as a tailor-made solution.
In a File::Find solution, where requirements are complex, the need to intersperse interface with functionality makes the solution more complicated than just inserting the requirement-meeting code in a recursive subroutine, although File::Find might well win for relatively trivial requirements.
Too true, Moron! Why, Perl itself, and the platforms it
runs on can hardly be said to work, as the requirements
they currently meet will surely change. At least
I assume so; I don't get around enough to really
have a valid opinion.
The question for your using any given module should be: "does it fit my requirements right now?". If the answer is "yes", then you use it. If it's "almost", then you can either patch the module to your own specifications or roll your own. If it's "no", then you make your own and upload it to CPAN for others to use (if that's appropriate). To say that no module will ever fit your requirements is lunacy.
There is another point that I haven't mentioned: Even though a module may be 99% fit for a purpose, it can still mean 300% extra code to overcome that compared with hand-rolling. This happens so often with File::Find where a complex requirement still only means one extra line per feature in a hand-rolled subroutine, but needs three or four lines of interface plus ten basic lines of code to use the CPAN (in fact core) module, that therefore I find myself not using that module any more.