Re^4: File::Temp randomness when forking

in reply to Re^3: File::Temp randomness when forking
in thread File::Temp randomness when forking

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.

thor

The only easy day was yesterday

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

Replies are listed 'Best First'.
Re^5: File::Temp randomness when forking by Moron (Curate) on Nov 30, 2005 at 09:46 UTC
If it's lunacy then why say it. This post seems to be a classic straw man. The rest of your points have already been made by me and others. -M Free your mind	[reply]
Re^5: File::Temp randomness when forking by Moron (Curate) on Nov 30, 2005 at 09:57 UTC
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.	[reply]
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]

In Section Seekers of Perl Wisdom