in reply to = for lists and hashes?

Default values for hashes are easy (and the common idiom for configs...): 
#!/usr/bin/perl -w

my %defaults = (name => "George", age => 26);
my %config = (age => 18);

my %hash = (%defaults, %config);

print "$_ : $hash{$_}\n" foreach (keys %hash);

[download]
Any keys defined in %config will overwrite any keys in %defaults, but if the key isn't in %config the default will prevail. If I'm not mistaken this in the Perl Cookbook somewhere.

Don't know how you'd only set part of an array without setting all of it without doing something ugly and iterating through each item in each array and seeing where there's a config value and where there's a default.

Gary Blackburn
Trained Killer

Replies are listed 'Best First'.
Re: Re: = for lists and hashes?
by skazat (Chaplain) on Mar 20, 2002 at 23:01 UTC

    I see what you're doing,

    I use that method too in a different project, but I'd really like the hashes and friends to be named the same in the Config module and the config file, that way, we don't get confused. There's more than one hash in the config, but if all I had was name => value pairs, this would be the way to go.

    Thanks

     

    -justin simoni
    !skazat!

[reply]
      I use that method too in a different project, but I'd really like the hashes and friends to be named the same in the Config module and the config file, that way, we don't get confused.

      I cannot stress enough the potential danger in this. Besides the obvious fact that someone could break security on the owning UID for that file and insert malicious code, there is another, more dire possible effect: you may have to maintain this code.

      What you are currently doing is very fragile, almost completely unscalable, and quite unreadable to someone looking at the code without the benefit of having been there from the beginning. It is far better to develop a regular habit of using a configuration file that is not itself code. Not only does that make for fewer maintenance headaches, it opens the possibility of sharing config resources between applications, moving parts of the application to more modular designs, and a general sense of ease in the world at large.

      If you are not fond of the idea of writing Yet Another Configuration Parser, I recommend starting with examination of AppConfig, Config::General, ParsePlainConfig and XML::Config. Not surprisingly, given Perl's strong text-manipulation abilities, there has been quite a lot of work done in terms of flexible configuration tools.

      --rjray

[reply]

In Section Seekers of Perl Wisdom