Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^4: File::Temp randomness when forking

by thor (Priest)
on Nov 29, 2005 at 20:33 UTC ( #512764=note: print w/ replies, xml ) Need Help??


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
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

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.
      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

        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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://512764]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (6)
As of 2014-09-17 00:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (55 votes), past polls