Simple Cases

Simple cases are handled by getargs(): named arguments should either be all mandatory or all optional, and there is no provision for specifying a default value for optional parameters.

The getargs() routine and its cousin cgetargs() have two different interfaces, depending on whether the arguments are all mandatory or all optional. We'll only specify for getargs(), but the signature of cgetargs() is identical.

getargs arglist, options, arg_spec1, arg_spec2, ...

We'll be ignoring the options argument from our discussion. See the Options section for details.

All the routine formal arguments specified by arg_spec1, arg_spec2, etc... are mandatory. If arg_spec1 is only a name, then it specifies a mandatory formal argument of that name, which can be of any type, even undef. If the name is followed by "=type" then "type" specifies the argument type: usually a reference type, unless 'i', 'n' or 's' is used for integer, natural and string scalars.

Currently, types 'i', 'n' and 's' all mean the same thing: that the argument must be a scalar. A future implementation will probably ensure 'i' and 'n' hold integers and natural numbers respectively, 's' being the placeholder for anything else that is defined.

For instance:

    foo               expects mandatory "foo" of "-foo" argument (undef ok)
    foo=s             idem, and argument cannot be undef or reference
    foo=i             value of argument -foo must be an integer
    foo=My::Package   foo is a blessed object, inheriting from My::Package
    foo=ARRAY         foo is an ARRAY reference
    

The rule for determing whether "foo=X" means "foo" is a reference "X" or "foo" is an object whose class is an heir of "X" depends on the argument value at runtime: if it is an unblessed ref, strict reference equality is expected. If it is a blessed ref, type conformance is based on inheritance, as you would expect.

Example:

    sub f {
        my ($port, $server) = getargs(@_,
            qw(port=i server=HTTP::Server));
    }
    

Some calls:

    f(-server => $server, port => 80);  # or -port, since - is optional
    f(port => 80, server => $server);
    f(server => $server);               # WRONG: missing mandatory -port
    f(server => 80, port => 80);        # WRONG: -server not an HTTP::Server
    f(server => undef, port => 80);     # WRONG: -server cannot be undef
    

By default, named argument processing is case-sensitive but there is an option to ignore case.

getargs arglist, options, array_ref

This form specifies that all the formal arguments specified in the array_ref are optional. Think of the '[' and ']' (which you'll probably use to supply the reference as a manifest constant) as syntactic markers for optional things. In the traditional Unix command line description, something like:

    cmd [-a] [-o file]
    

typically denotes that options "-a" and "-o" are optional, and that "-o" takes one argument, a file name. To specify the same things for routine arguments using getargs():

    sub cmd {
        my ($a, $o) = getargs(@_, [qw(a o=s)]);
    }
    

Here however, the "-a" argument can be anything: we're not specifying switches, we're specifying named arguments. Big difference.

Some calls:

    cmd();                      # OK
    cmd(-a => undef);           # OK -a accepts anything, even undef
    cmd(-a => 1, -o => "..");   # OK
    cmd(-a => 1, -o => undef);  # WRONG: -o does not accept undef
    cmd(-x => 1);               # WRONG: -x is not a known argument name
    

It is important to note that there can only be tuples when using named arguments, which means that the routine is called with an even number of arguments. If you forget a "," separator between arguments, getargs() will complain about an odd number of arguments (provided the resulting code still parses as valid Perl, naturally, or you'll never get a chance to reach the execution of getargs() anyway).

cgetargs same args as getargs

The cgetargs() routine behaves exactly as the getargs() routine: it takes the same arguments, returns the same list. The only difference is that the first time it is called, it builds a routine to process the arguments, and then calls it.

On subsequent calls to cgetargs() for the same routine, the cached argument parsing routine is re-used to analyze the arguments. For frequently called routines, this might be a win, even though Perl still needs to construct the argument list to cgetargs() and call it.

cxgetargs same args as getargs

Like cgetargs(), but with extended specifications allowing to specify defaults for non-mandatory arguments. Be careful: those defaults are deep-cloned and "frozen", so to speak.

Complex Cases

The xgetargs() routine and its cousin cxgetargs() (for the caching version) allow for a more verbose description of named parameters which allows specifying arguments that are mandatory or optional, and also give default values to optional arguments.

xgetargs arglist, options, name => type, ...

We'll be ignoring the options argument from our discussion. See Options for details.

There can be as many name => type tuples as necessary to describe all the formal arguments of the routine. The name refers to the argument name, and type specifies both the mandatory nature and the expected type. You may use name or -name to specify an argument called name, and the caller will also be able to spell it as he wishes. The type is encoded as follows:

    "i"      mandatory integer (scalar)
    "s"      mandatory string (scalar)
    "TYPE"   mandatory ref of type TYPE, or heir of type TYPE
    undef    unspecified type, but mandatory argument
    ["i"]    optional integer
    ["s"]    optional string
    ["TYPE"] optional ref of type TYPE, or heir of type TYPE
    

For optional parameter, an optional second value may be inserted in the list to specify a default value. For instance, the tupple:

    'y' => ['HASH', { a => 1, b => 2 }]
    

specifies an optional named argument y, which is expected to be a HASH reference, and whose default value is the hash given.

You may specify an expression as default value instead of giving a manifest constant, but BEWARE: the cxgetargs() routine will take a snapshot of your expression when building its analyzing routine. It's of no consequence when using a manifest constant, but when using an expression, it will be evaluated once and the result of that evaluation will be taken as the manifest constant to use subsequently (and this does not mean the same reference will be returned, only the same topological structure as the one we evaluated during caching).

Example:

    sub f {
        my ($x, $z) = cxgetargs(@_,
            -x  => 'i',                 # -x mandatory integer
            -z  => ['n', -20.4],        # -z optional, defaults to -20.4
        );
    }
    f(x => 1, z => {});     # WRONG: z is not a numerical value
    f(z => 1, x => -2);     # OK
    f(-z => 1);             # WRONG: mandatory x is missing
    f(-z => undef);         # WRONG: z cannot be undef
    

Remember that we are dealing with named parameters for a routine call, not with option parsing. Therefore, we are always expecting an even number of arguments, and those arguments are tuples name => value.

Options

All the getargs() and xgetargs() routines take an optional hash reference as second argument. Keys in this hash define options that apply locally to the call. In the case of caching routines, e.g. cxgetargs(), the options are only considered the first time, when the analyzing routine is built, and are ignored on subsequent calls. Therefore, it is wise to use manifest constants when specifying options, or use the non-caching function family instead if your options need to be dynamically computed (please, don't do that).

Options given there must be spelled out with the leading "-" and are case sensitive. To enable an option, give a true value. For instance:

    sub f {
        my ($x, $z) = cxgetargs(@_,
            { -strict => 0, -ignorecase => 1 },
            -x  => 'i',                 # -x mandatory integer
            -z  => ['n', -20.4],        # -z optional, defaults to -20.4
        );
    }

supplies two options, turning "-ignorecase" on and "-strict" off.

The available options are, in alphabetical order:

-extra

Whether to report extra unknown arguments at the end of the argument list. Example:

    my ($x, $y, @extra) = getargs(@_,
        { -extra => 1, -strict => 0 }, qw(x y));
    

Your setting is forced to false when "-strict" is true. The default value is the negation of the boolean "-strict" setting, which means the above can be rewritten as:

    my ($x, $y, @extra) = getargs(@_, { -strict => 0 }, qw(x y));
    

which will implicitely set -extra to be true. This is usually what you want when not strict, i.e. get at the other parameters. Assuming we were writing the above for a function f(), calling:

    f(-x => 1, -y => 2, -other => 5);
    

would set:

    @extra = (-other => 5);
    

An alternative when you are not strict is to make use of the "-inplace" option to edit @_ inplace.

-ignorecase

Turn case-insensitive named parameters. False by default. Actually, if not explicitely specified, the default setting depends on the way "Getargs::Long" was imported within the package scope. If you said:

    use Getargs::Long;
    

then the default is indeed to be case-sensitive. However, if you said:

    use Getargs::Long qw(ignorecase);
    

then the default for the package scope is to be case-insensitive. You may still specify the "-ignorecase" option to force case sensitivity on a per-routine basis, although I would never do such a thing and stick to a uniform case sensitivity on a package basis.

-inplace

Whether to edit the routine's argument list inplace, removing processed arguments as they are found and leaving unprocessed ones. False by default.

Your setting is forced to false when "-strict" is true, naturally, since an unknown argument is an error.

-strict

Whether unknown named parameters are fatal. True by default. When "-strict" is true, the "-inplace" and "-extra" options you may specify are ignored and forced to false.