# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 02:51 am:
> I did not notice the go_shop problem. But I think it's trivial to
>solve that with Getopt::Long:
>
>my @conf_fishes = read_conf("fish"); # get qw(trout)
>my @opt_fishes = qw();
>my $opt_nofish = 0;
>Getopt::Long::GetOptions(
> "fish=s" => [EMAIL PROTECTED],
> "no-fish" => \$opt_nofish,
>);
>@conf_fishes = qw() if $opt_nofish;
>my @fishes = (@conf_fishes, @opt_fishes);
Yes. You can solve it. It's not really trivial by the time you add
meats, cheeses, breads, and mustard though. All of these things come
in many "flavors" and you might have a config file with your favorites
listed in it so that running "go_shop" with no arguments gives you a
routine trip, but you want to be able to change these things when you
get bored of the same-old options.
These 4 extra lines multiply by 5 items so far.
> Who said the variable to save the "no-fish" status has to be
>revelant with the "fish" variable anyway? If they are saved in
>different variables, the order doesn't matter, does it?
What I'm trying to do with Getopt::Modern here is to establish some
conventions which allow this to happen internally. This saves the
author some code and gives the user a guaranteed consistent experience
with multiple programs.
The debate on the usefullness of '--no-' appears to say it's useful.
The debate on its behavior says that there are historical (and
convenience) reasons to keep its evaluation in command-line order.
What I'll probably end-up with is something like '--un-' performing the
above task of initializing internal values.
--Eric
--
"Everything goes wrong all at once."
--Quantized Revision of Murphy's Law
---------------------------------------------
http://scratchcomputing.com
---------------------------------------------
