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

My larger projects require params to be passed in via hashref for simplicity, but I'm wondering from a user perspective which is more convenient... storing the non-core params for continuous use, or reset the non vital ones so they have to be resent in.

If they are stored, it requires a reset on the params that you want changed (ie. you have to reset a parameter to false on a subsequent run with the same object). What's your opinion on storing or wiping params?

  • Comment on User preference: To store params or not

Replies are listed 'Best First'.
Re: User preference: To store params or not
by jeffa (Bishop) on Jul 28, 2015 at 22:46 UTC

    I think i would have the defaults in a temporary hash and merge that with the users preferences: 

    my %default = ( foo => 1, bar => 2);
my %users = ( bar =>3 , baz => 2 );
my %CONFIG = ( %default, %users ); # user overrides default

    [download]

    This way you shouldn't have to reset them, they get applied "on the fly."

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]

      Thanks jeffa. I'm trying to implement a cache for data, and it requires past params to be known. I'm seriously considering writing a is_deeply type filter for Memoize to do this work so I don't have to.

[reply]
[d/l]
Re: User preference: To store params or not
by crusty_collins (Friar) on Jul 29, 2015 at 15:09 UTC
    I use something like these configs in my previous job. 
    use strict;
use warnings;
use Getopt::Long;
use Data::Dumper;

my $log;
my $account;

my $href = {};

my $globalConfig = "globalConfig.cfg";
my $localConfig = "localConfig.cfg";


GetOptions (
    "log=s" => \$log,
    "account=s" => \$account
);

&getEnv($globalConfig); 
&getEnv($localConfig); 

print Dumper $href;

exit;

sub getEnv {
#    my $href = shift(@_);
    my $file = shift(@_);
    
    unless ( -e $file ) {
        print "Could not find $file \n";
        exit(1);
    }

    open ( FILE , "< $file" );

    while (<FILE> ) {
        chomp;

        next if $_ =~ /^\#/;

        my ($key, $variable) = split(/=/,$_,2);
        if ( $variable && $key ) {
            $variable    =~ s/\s+//g;
            $key        =~ s/\s+//g;
            $href->{config}->{$key} = $variable;
        }
    }
    close FILE;
}

    [download]
    globalConfig.cfg 
    #comment
log=global.log
dir=c:\somepath

    [download]
    localConfig.cfg 
    #comment
log=local.log
account=C123454

    [download]
    output 
    $VAR1 = {
          'config' => {
                        'account' => 'C123454',
                        'log' => 'local.log',
                        'dir' => 'c:\\somepath'
                      }
        };

    [download]
[reply]
[d/l]
[select]
Re: User preference: To store params or not
by Laurent_R (Canon) on Jul 29, 2015 at 09:41 UTC
    I once wrote an interface to a low-level API accessing a database. The point was to simplify the access to data by hiding many of the gory details of the low level API. One of the things I did in my interface module was to store in closures most of the information I did not want the module user (usually me) to have to care about (connection ID, transaction ID, error buffer ID, etc.). The user would just need to call an init function at the beginning of the program and then simply call the functions to query the data, the module taking care of the underlying details. I do not know if this applies to your case, but I was quite happy with this solution which made our lives much easier.
[reply]
Re: User preference: To store params or not
by locked_user sundialsvc4 (Abbot) on Jul 29, 2015 at 13:18 UTC

    And I once did something very similar to jeffa’s suggestion, defining an object which initialized a set of defaults.   A method was provided which allowed you to override those defaults using the content of the method’s own parameter-list, @_, thus defining the defaults for all subsequent calls to the extent that you didn’t want to use the “canned” ones.

    This, I think, is a very important feature, because if you are obliged to repeatedly specify the same things to many calls, you will eventually fail notice that some parameter was left out, or that words two were accidentally specified in the wrong order, and so on.   ;-)   When you are reading a lot of source code, in Paris in the the Springtime, it is easy for your eye to see what it expects, not what the compiler will see.

Back to Seekers of Perl Wisdom