# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 01:03 am:
>> Ok, and maybe I showing my age here, but is *this* where the
>> negated-options thing comes from? I.E. is this the historic (and
>> entire) reason for having the 'foo!' syntax in Getopt::Long?
>
>No, it's because of a) defaults. Sometimes a flag is enabled by
>default, sometimes its disabled by default. Having both the --foo and
>--no-foo options it is always possible to exactly define what you want
>the current invokation of the command to do, regardless of any default
>settings. It's user-friendly redundancy.
Ok. Then my previous argument stands. If the --no- means "unset any
hard-coded or config-file defaults", then it shouldn't be evaluated in
command-line order.
>And b) mixing options and arguments, where "--foo arg1 --no-foo arg2"
>means that arg1 is processed with --foo and arg2 with --no-foo.
This is not something I'm trying to address. If arg1 and arg2 are
arguments and foo is a simple option, then it arg1 and arg2 are simply
passed through. If they needed to be processed in context, foo
wouldn't be a simple option. That's just my take on it.
--Eric
--
"...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of their
tendency to spend it on lawn ornaments."
--Neal Stephenson
---------------------------------------------
http://scratchcomputing.com
---------------------------------------------
