using GetOpt in a sub

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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.

Re: using GetOpt in a sub

On 6/1/2014 14:56, wrote:
Quoted text here. Click to load 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, $h;


Re: using GetOpt in a sub

Quoted text here. Click to load it

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.

Tim McDaniel,

Re: using GetOpt in a sub

Quoted text here. Click to load it

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) = @_;

Re: using GetOpt in a sub writes:
Quoted text here. Click to load it

Getopt usually works on a list of strings.

Quoted text here. Click to load it


Quoted text here. Click to load 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 ...

Site Timeline