Odud has asked for the wisdom of the Perl Monks concerning the following question:

I need a small amount of static data in a script that is called about 200 times per day max (spread through an eight hour period). The static data will only change very infrequently (about once a month at first and probably never after 6 months). I suppose I should put it in a config file read by the script but this seems a lot of effort for little gain - particularly as it would need error handling, content validation, defaults etc. It would be much easier to qw/ / it into a list and take the small hit of having to redistribute the code just to implement a config change. The code is only ever going to live on two servers and they will always have identical versions of the config data. As soon as I needed multiple versions of the config data I would move to a file solution - but in this case it will never (!) happen. Does anyone have any useful guidelines/rules that they follow for situations like this?

Replies are listed 'Best First'.
RE: Code versus Config
by jjhorner (Hermit) on Jun 05, 2000 at 16:02 UTC

    You are setting yourself up for a fall by immediately limiting the lifespan of your script. It has come back to haunt enough programmers, so you are better off doing a little hard work now to save you work later. Besides, having an elegant, easy to manage solution is something you can show off. I know I like having pretty code (if I can write pretty code).

    Who knows? If they like it enough, they may decide to stick with your solution for a long time to come. Think of how that will make you feel.

    In short, this seems like a script used often enough to do it right at the beginning. Don't get lured into the "quick now, more work later" mindset. Not good. 

    J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/
[reply]
      The script won't have a limited life - I expect it to be used for a long while yet. It's just that it will go through a "tuning" phase before settling down. I appreciate what you are saying about doing it right first time but I think there is a need to get the balance right between the code that performs the script functions and the code that performs the script housekeeping and control. (Clumsily worded but I hope you see what I'm getting at) For most of the stuff that I write I would agree with you entirely - an ounce of prevention... etc. (I can't remember the whole saying) and I sometimes go a bit over the top "don't ever assume anything is correct or anything ever worked" - it's just the borderline cases where I worry about the ratios.
[reply]
Simple config solution
by Corion (Patriarch) on Jun 05, 2000 at 16:51 UTC

    In your case, maybe putting the configuration data in the DATA section could help.

    If you store your "sane" configuration data in the DATA section and initialize your stuff from there, you can after that go looking if the user specified another configuration file and read that in in the same manner you did read in your DATA section. Thus you have both, a single file that works and the option to have a configuration file.

    For an example on how to use the DATA section, go here (the sourcecode version of the node)

[reply]
      People have recommended putting the config into __DATA__ and this combined with an optional config file seems to me to be the best solution. If someone removes the config file then at least the script will continue to work with a reasonable set of defaults. Thanks to everyone who replied to this question.
[reply]
Re: Code versus Config
by Asim (Hermit) on Jun 06, 2000 at 00:09 UTC

    It's worth it, IMHO, to put your config info into a seperate file. I wrote a script for my former job where they needed real replication, not the hell to configure, broken stuff that NT does. It didn't take me long at all to build a config file, and it means that, when I left, they never have bothered me about that program since (I'm still in regular contact with 'em).
    And it has to; servers have an odd habit of changing w/o notice at my old place of work. :)
    As far as overhead, what I did was do a file test for last modified (which works on Win95 and NT, in case you needed to know) -- takes but a millsecond, and the benifits are obvious.
    Make it easy on your backups (or the persons who come next if you leave), and impress your PHBs ("see, you can edit it too, in a pinch"). :)

    ----Asim, known to some as Woodrow.
[reply]
(jcwren) RE: Code versus Config
by jcwren (Prior) on Jun 06, 2000 at 03:03 UTC
    I tend to agree with the other folks here about storing your data as a config file.

    However: You should provide an option to either display explicit information on how to create a config file if one does not exist, or (IMHO) better yet, provide an option for creating a config file programatically, with either sane defaults, or interspersed liberally with Sample data, put your schtuff here.

    And everyone here is right. If you think your script will only be around for a year or so, multiply by 10. Old software never dies...
[reply]
Re: Code versus Config
by chromatic (Archbishop) on Jun 07, 2000 at 02:24 UTC
    One very quick and not too dirty way to handle config files is a combination of eval and Data::Dumper. Just get your internal data structures all set up with what you want, and then use the module to make a file that'll set the variables back when you eval() it.

    That's not a very good explanation, is it? What Data::Dumper can do is turn an internal Perl data structure into a scalar of valid Perl code that can be stored on disk or in a database somewhere. Since it's valid Perl code, it's easily editable. Since it's a separate file, it can be changed without changing the script. Just another approach.

[reply]

Back to Seekers of Perl Wisdom