http://qs1969.pair.com?node_id=50839

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

I've spent the evening looking at the AppConfig module, trying to work out the best way to use it in my application.

The basic functionality I'm trying to create is fairly standard -

Now, because the methods that parse a configuration file, and the commandline, are one shot tasks, at first glance it would appear that I'm going to have to parse the commandline, save the parameters specified in a hash, read in the correct configuration file, then overlay the stored parameters with those just loaded.

This may be the right way to go about it, but something's nagging at me that I'm missing something. Which leads me onto the second half of my question...

I notice that I can find out the configuration values held in the AppConfig object with the following method (right terminology?) - $config_object->variable_name();

Should I therefore avoid storing the result of this method in another variable, calling this method each time I need the value, or is this the overhead equivalent of calling a function multiple times needlessly?

I've not yet sat down and investigated OO for myself yet, having merely picked up bits here and there (mostly from using other peoples perl modules), so be gentle if I'm way off track!

Pete

Replies are listed 'Best First'.
Re: AppConfig variables and OO
by ichimunki (Priest) on Jan 10, 2001 at 20:48 UTC
    If all your package is going to do is hold a single blessed reference to a hash, creating a special OO configuration package seems like an overhead inefficiency, both in terms of programming and execution. However, if the rest of your program uses OO design, you may want to. Instead of building a single config var get() method for each var, you might consider a permutation on the AUTOLOADER idea that allows you to specify a list of keys, and returns the values in that order. You might also consider not having a new() constructor to prevent polymorphous instances of configuration, and then write all methods as class methods.

    I haven't been impressed (on very cursory inspection) with what I've seen for config modules on CPAN yet, so please write a review if you use one and get a decent understanding of its strengths and weaknesses.

    update: on reviewing AppConfig, it sure looks like a robust module, worth the time to learn to use if you have more than trival configuration concerns.
[reply]

      Thanks for your reply - I've done some reading up of OO with Perl over the last 24 hrs, and have come to the conclusion that I'd best stick to traditional methods until I understand it a little more.

      Regarding AppConfig; I agree with your conclusions, although the only problem I've encountered so far is with the AppConfig::State VALIDATE option. If a parameter fails the validation, with PEDANTIC set to 0, the $config->args() method doesn't let you know what happened... as far as my testing shows.

      Other than that, it's a very useful module.

      Pete

[reply]
Re: AppConfig variables and OO
by Caillte (Friar) on Jan 10, 2001 at 20:34 UTC

    Consider the following:

    use Benchmark;

my $foo = "bar";
my $test = new tester();

my ($buffer, $i);

my $a1 = new Benchmark;
for( $i=1; $i<1_000_000; $i++ ) {
    $buffer = $foo;
}
my $a2 = new Benchmark;


my $b1 = new Benchmark;
for( $i=1; $i<1_000_000; $i++ ) {
    $buffer = $test->report();
}
my $b2 = new Benchmark;

my $diff1 = timediff($a1, $a2);
my $diff2 = timediff($b1, $b2);

print "Variable copying: " . timestr($diff1) . "\n";
print "Object copying: " . timestr($diff2) . "\n";


package tester;

sub new {
    my $class = shift;

    my $self = { 'foo' => "bar" };

    bless $self, $class;

    return $self;

}

sub report {
    my $self = shift;

    return $self->{'foo'};

}

    [download]

    Running this gives (on a 1ghz pc hobbled by Win2k):

    Variable copying: -1 wallclock secs (-0.81 usr +  0.00 sys = -0.81 CPU
+)
Object copying: -5 wallclock secs (-5.15 usr +  0.00 sys = -5.15 CPU)

    [download]

    Considering there are a million copies made of each the time difference isnt all that great. However, if all we wanted to do was code fast programs none of us would ever write OO :)

    In other words, use a variable if calling the object is too much work :)

    However there are many other reasons to code this way... have a look at This file and especially this file for some basic guidelines and explanation of OO programming.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom