using GetOpt in a sub

[oldyork90]

Is this done?

Instead of calling a sub with a defined set of parameters, call it instead with a single string. This string is tokenized and then GetOpt called to sort out the mess.

As some of my sub get "optiony" I see a use for this construct. While I should probably create new subs for some of the option configurations, I was curious about this use of Getopt.

I see Getopt allows for a user's @ARGV.

Always curious about the way the pros do it.

Thanks in advance.

 

[$Bill]

Is this done?

Instead of calling a sub with a defined set of parameters, call it instead with a single string. This string is tokenized and then GetOpt called to sort out the mess.

As some of my sub get "optiony" I see a use for this construct. While I should probably create new subs for some of the option configurations, I was curious about this use of Getopt.

I see Getopt allows for a user's @ARGV.

Always curious about the way the pros do it.

You're more likely to see multiple args passed as a hash instead of a string:

use strict;
use warnings;

do_it ('x' => 1, 'y' => 2);

sub do_it {
my %h = @_;
printf "x=%s y=%s\n", $h{'x'}, $h{'y'};
}

__END__

 

[Tim McDaniel]

You're more likely to see multiple args passed as a hash instead of a string:

I've never seen any getopt-type processing for subs, and I'd strongly
recommend against it. My company passes hashes for args.

getopt is intended for command lines being typed by the user, so
having a premium on brevity, and they are dynamic and casual and often
complicated. Code is write once run many, and usually has much
simpler invocation conventions.

I think sub calls are clearer if "preparsed", be it represented by
hash, lists or arrays of arguments, or whatever: the parsing is done
once when writing the code and you don't have to worry about the
correct shortcut for --frobotz or whatever. It's also much more
efficient, but that's a concern only for the subs called most often.

 

[Rainer Weikusat]

Is this done?

Instead of calling a sub with a defined set of parameters, call it
instead with a single string. This string is tokenized and then
GetOpt called to sort out the mess.

Getopt usually works on a list of strings.

As some of my sub get "optiony" I see a use for this construct. While
I should probably create new subs for some of the option
configurations, I was curious about this use of Getopt.
[...]

Always curious about the way the pros do it.

This depends somewhat on how subroutines are being used. There are
basically two competing approaches here:

1. "I have to dig a tunnel below Mordor with a teaspoon until tomorrow
so I'd better start shoveling!" aka 'subroutines are not being used'
(except insofar they can be downloaded from the internet free of
charge). That's the traditional way to avoid structuring a program and
much beloved by people with an excellent short-term memory who prefer
to 'keep on shoveling' until the problems runs out instead of designing
a machine which solves the problem. In this case, how subroutine
arguments are dealt with pretty much doesn't matter: There's exactly one
'subroutine' and maybe it had some arguments 6,500 lines in the past but
nobody can remember if it did and in any case we gotta keep on shoveling
instead of being distracted with silly questions like that.

2. Subroutines are being in a way known as 'functional decomposition',
that is, each subroutine corresponds with an 'abstraction layer' and it
is invoked by more abstract subroutines and invokes less abstract
ones. In this case, there'll be many subroutines and they're typically
short (30 lines of code or less). Likewise, parameter list are going be
short (1 - 4 parameters) and arguments will usually be accessed by
position because that's faster and more elaborate schemes aren't
needed. Should an elaborate scheme for dealing with subroutine arguments
be needed, this would indicate that the subroutine in question does too
many different things and should be further decomposed.

I usually prefer 2) becauses this provides a reasonably simple way to
solve complicated problems, however, creating seriously complicated
solutions to simple problems is also very popular ...

 

[Rainer Weikusat]

You're more likely to see multiple args passed as a hash instead of a string:

use strict;
use warnings;

do_it ('x' => 1, 'y' => 2);

sub do_it {
my %h = @_;
printf "x=%s y=%s\n", $h{'x'}, $h{'y'};
}

That's not really passing arguments as a hash, it is equivalent to

do_it('x', 1, 'y', 2)

except that the '' could be omitted when using =>. This four-element
list is then used to initialize a hash and the elements on the list
alternatingly become hash keys and associated values. This is similar to
the way 'command-line options' are usually handled: There's an argument
naming 'the option', followed by an argument giving its value. Unless a
subroutine takes a lot of different arguments in no particular order,
passing arguments by position is more sensible, ie

sub do_it
{
my ($x, $y) = @_;
}