Re^3: Getopt::Long to define or not to define?

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.

Comment on Re^3: Getopt::Long to define or not to define?

Replies are listed 'Best First'.
Re^4: Getopt::Long to define or not to define? by shemp (Deacon) on Mar 07, 2005 at 23:27 UTC
Yes, actually, i am saying that there are cases where this is useful. One i just thought of that doesnt actually apply to input, but rather to return values is the built-in wantarray(). The return values are as follows undef if the sub was called in void context defined but false if the sub was called in scalar context true is the sub was called in list context.	[reply]