jordanh has asked for the wisdom of the Perl Monks concerning the following question:

I use Getopt::Long.

In the docs it gives all the examples in the form: 

my $tag = '';       # option variable with default value
GetOptions ('tag=s' => \$tag);

[download]
Where the option variables are initialized to '' (or some other default).

I typically declare the option variables, but don't give them an initial value, depending on the fact that they are undefined to flag to me that the option is unspecified (as opposed to set to a false value).

I think this mode of operation is supported, but I'm wondering if there isn't a pitfall or practice that I'm not thinking of here. Actually, I think there's a clear implication that this mode is supported in the docs where it says:

The call to GetOptions() parses the command line arguments that are present in @ARGV and sets the option variable to the value 1 if the option did occur on the command line. Otherwise, the option variable is not touched. Setting the option value to true is often called enabling the option.

My way of working with it seems natural to me, but the examples and other people's code often seems to follow the other style.

I recognized the pitfall that an undefined value tests false and that I need to explicitly test for defined.

Is there anything else I'm missing?

Replies are listed 'Best First'.
Re: Getopt::Long to define or not to define?
by moot (Chaplain) on Mar 04, 2005 at 20:26 UTC
    The normal reason for setting a value (as opposed to leaving a parameter undefined) is to provide a sane default for the parameter. If you have no need for such a default, by all means leave the value undefined - caveat that you will have to explicitly test for this later, of course.
[reply]
      I've used this behavior to set defaults, but I've more often tested explicitly for undefined and set the default value in code.

      True, it's not as lazy as it could be, but it's more consistent for me because I tend to have a block of code that tests all the parameters for sanity, mutual exclusivity and the like right after the call to GetOptions().

      It's just my style, I guess.

[reply]
Re: Getopt::Long to define or not to define?
by shemp (Deacon) on Mar 05, 2005 at 00:07 UTC
    I cant come up with a good example right now, but there are definitely times where i'd want false (but defined) to indicate a behavior different than for undef.

    Its similar to the question of why would i want to allow null values in a column in a DB table.

[reply]
      I cant come up with a good example right now, but there are definitely times where i'd want false (but defined) to indicate a behavior different than for undef.

      Likely, shemp was thinking along the lines of an optional numeric option. A crazy example I can think, goes along the lines of "how many errors will this parser tolerate before throwing an exception".

      You could leave the option undef to mean "no amount of errors will make me throw an exception", zero (also false) to mean "allow no errors at all" and a positive value (true) to mean "allow for up to this many errors".

      However, the most common usage is to have undef stand for "not specified/wanted" and a true value for the contrary.

      Best regards

      -lem, but some call me fokat

[reply]
        Maybe I'm not understanding what's being said here, but is shemp arguing for my style? It seems only if you have undefined clearly distinct from false and you explicitly test for it that you can really benefit from "false (but defined) to indicate a behavior different than for undef".

        One cool possibility that I thought of last night that is made possible by my style is this: If the script has some debug level parameter passed in (or built-in perhaps), the script would report to you informationally when you are setting a parameter to its default value. This might be helpful information to the user and it would not be possible if you set the default value before calling GetOptions.

[reply]

Back to Seekers of Perl Wisdom