in reply to Re^3: GetOpt Organization (!hash)
in thread GetOpt Organization

i'm a bit unsure if i guessed right what you mean 

     nose ($options{foo}, $options{bar});

[download]

That covers "I can often make it clearer which options impact the behavior of a particular sub". But it doesn't cover any of the other cases.

If there are any places that have access to the hash, then I have to go search in those places to see if 'foo' or 'bar' is used in those places. Of course, perhaps you never give access to the hash to any place, in which case what is the point of having a hash?

But it is fairly common for some command-line options to impact many different places such that it is a pain to pass those options through every layer to every place that might care. And one of the benefits of variables is that you can distinguish the scope of each option. 

our $Verbose = 0; # Used tons of different places so is global

my @files = cmd_opts( @ARGV );
...

sub cmd_opts {
    my @args = @_;
    my $mod = 0;
    GetOptionsFromArray( \@args,
        'verbose|v'  => \$Verbose,
        'modified|m' => \$mod,
    ...
    return find_files( $mod, @args );
}

[download]

Without looking any further, I can tell that --modified only impacts find_files().

Another advantage is that you don't have to match the name you use in your code with the name you use on the command line. It might make perfect sense for --line-number to mean that you want each output line to be labeled with a number (like 'grep') while, in the code, line_number means the number that will be prepended so --line-number actually sets $label_output.

It is nice to improve the command-line interface with better option names without having to do a global search/replace in the code or to refactor code to use better names without having to break backward compatibility of the command-line interface.

But I still think the biggest advantage is that "use strict" tells me if I spell the option name differently in different places, catching a bug for me.

- tye        

Replies are listed 'Best First'.
Re^5: GetOpt Organization (only)
by karlgoethebier (Abbot) on Mar 10, 2015 at 11:08 UTC

    Thank you very much tye for your explanation.

    I try to think this one step ahead.

    Consider this simple example:

    my %hash;

foo(\%hash);

bar(\%hash);

sub foo{
    my $ref = shift;
}

sub bar {
    my $ref = shift;
}

# perhaps many more

    [download]

    So a cleverle might come and say: "Passing around these refs and dereferencing them all the time is a pain" - i make it so instead:

    our %hash;

foo();

bar();

sub foo{
    our %hash;
}

sub bar {
    our %hash;
}

    [download]

    IMHO this idea is, with all due respect, debatable. Or it is against the pure doctrine, as you like.

    My best regards, Karl

    P.S.: Daddy says globals are the root of all evil ;-)

    «The Crux of the Biscuit is the Apostrophe»

[reply]
[d/l]
[select]
      For a lot of programs not using %opt makes sense, but for a lot of programs using %opt makes sense ...

      if all the options do is set values that get passed to a template after validation, having it as $prefix instead of $opt{prefix} ...

      if things are going to end up in a hash anyway, might as well start out in a hash :)

[reply]

In Section Seekers of Perl Wisdom