Re^5: File::Temp randomness when forking

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.

Comment on Re^5: File::Temp randomness when forking

Replies are listed 'Best First'.
Re^6: File::Temp randomness when forking by thor (Priest) on Nov 30, 2005 at 12:11 UTC
So what you're saying is that it's easier to come up with a from-scratch solution than to take one that's 90% there and make modifications? Ummm... thor `The only easy day was yesterday`	[reply]
Re^7: File::Temp randomness when forking (reuse) by tye (Sage) on Nov 30, 2005 at 17:08 UTC
So what you're saying is that it's easier to come up with a from-scratch solution than to take one that's 90% there and make modifications? Ummm... Yes. Exactly. I can usually roll my own replacement for File::Find faster than I can figure out exactly how to use File::Find correctly for the particular problem I'm trying to solve. Sure, File::Find likely has 90% of the solution I need already written. But that 90% usually constitutes 5% of File::Find's functionality and is something I can write in a few lines in a few minutes (yes, I know the classic 4 traps to avoid when writing a File::Find replacement -- if you don't, then either use File::Find or go learn them, perhaps by reading and understanding File::Find's source code). That takes me less time than looking up File::Find's documentation and finding the bits I need in there, but just barely. However, most of the time, I need to summarize things by directory or detect empty directories or something else that is trivial to do with a hand-rolled replacement but that is frustratingly difficult to figure out whether it is even possible when using File::Find much less do all of the extra work to cram the solution into File::Find's frustratingly restrictive call-back API. If you have a desk whose surface is 90% big enough for what you need, it is usually easier to throw an old door on a couple of saw horses to get your needs 100% satisfied (not using the desk at all) than it is to modify the desk to add 10% to its surface. Though I'm sure it is a fine desk. - tye Thanks for pointing out the need for s/through/throw/, BrowserUK	[reply]