Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^2: File::Temp randomness when forking

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

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

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

  • Comment on Re^2: File::Temp randomness when forking

Replies are listed 'Best First'.
Re^3: File::Temp randomness when forking
by Moron (Curate) on Nov 29, 2005 at 13:25 UTC
    (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.


    Free your mind

      > No module works at all in an absolute sense.

      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.


      The only easy day was yesterday

        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.


        Free your mind

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://512615]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2018-06-19 22:05 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (115 votes). Check out past polls.