using GetOpt in a sub

Discussion in 'Perl Misc' started by oldyork90, Jun 1, 2014.

  1. oldyork90

    oldyork90 Guest

    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.
     
    oldyork90, Jun 1, 2014
    #1
    1. Advertisements

  2. oldyork90

    $Bill Guest

    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__
     
    $Bill, Jun 2, 2014
    #2
    1. Advertisements

  3. oldyork90

    Tim McDaniel Guest

    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, Jun 2, 2014
    #3
  4. Getopt usually works on a list of strings.
    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, Jun 2, 2014
    #4
  5. 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) = @_;
    }
     
    Rainer Weikusat, Jun 2, 2014
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.