using GetOpt in a sub

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

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

  2. $Bill Guest

    On 6/1/2014 14:56, wrote:
    > 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__
     
    $Bill, Jun 2, 2014
    #2
    1. Advertising

  3. Tim McDaniel Guest

    In article <lmgljh$2kb$>, $Bill <> wrote:
    >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.

    --
    Tim McDaniel,
     
    Tim McDaniel, Jun 2, 2014
    #3
  4. writes:
    > 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, Jun 2, 2014
    #4
  5. "$Bill" <> writes:
    > On 6/1/2014 14:56, wrote:
    >> 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'};
    > }


    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. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Praveen

    using getopt() more than once

    Praveen, Dec 19, 2004, in forum: C Programming
    Replies:
    2
    Views:
    451
    Giovanni
    Dec 19, 2004
  2. Ben
    Replies:
    2
    Views:
    962
  3. Lawrence D'Oliveiro

    Death To Sub-Sub-Sub-Directories!

    Lawrence D'Oliveiro, May 5, 2011, in forum: Java
    Replies:
    92
    Views:
    2,174
    Lawrence D'Oliveiro
    May 20, 2011
  4. Sunil
    Replies:
    5
    Views:
    366
    Bart Lateur
    Aug 14, 2003
  5. Sunil
    Replies:
    8
    Views:
    165
    Benjamin Goldberg
    Sep 2, 2003
Loading...

Share This Page