The reason I'd want one file is to make it easier to admin when updates are made available, which happens often. Testing can be done easier by simply running a separately named script. The script and supporting files are hardcoded to run out of a specific directory, so I cannot create a new one with updated module files.

I'm going to address each of these in a separate comment.

  1. The reason I'd want one file is to make it easier to admin when updates are made available, which happens often.

    This is a fallacy. It's actually easier to manage changes made to very small items that are independent from one another. That way, you know that the change's impact is limited to a very small area. This is called decoupling, and it is an extremely important concept in change manamagement.

  2. Testing can be done easier by simply running a separately named script.

    It is much easier to test small, independent items than it is to test a big complex thing. For one thing, you can more easily determine what the failure cases are. Plus, if you have a monolithic thing, you have to take into account every interaction every time you make a change. If you have a bunch of small, decoupled bits of code, you only have to worry about how the one piece you're looking at behaves. It's easier to work with 100 lines at a time than 10,000 lines.

  3. The script and supporting files are hardcoded to run out of a specific directory, ...

    Just because it's only ever going to run with one set of parameters doesn't mean you should limit yourself to that. Hard-coding is almost never good, outside of a configuration file. For one thing, you can't test the code outside of a production environment. If you have a configuration file, you can test in a temporary directory and feel confident that it will work in the production directory.

I once spent two days adding configuration to a database connection class so that I could test it. I've yet to actually work with more than one database, but the ability to add 300 tests was absolutely critical. For one thing, I fixed a bug that had been annoying me (and my users) for three months. Impossible to do if I had to work directly with the database. (As in, impossible for me to make the effort to do it, not impossible from a technical sense.)

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

In reply to Re^3: Global variable declarations with packages by dragonchild
in thread Global variable declarations with packages by spoulson

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.