Knobs should be left to right - why (some) getopts are broken

There are two main styles of command line argument or options parsers - which my subculture calls "knobs".

My preference is to parse strictly left to right.

Another common approach is to partse all the knobs, possibly out of order.  Often the last value written for a knob overrides all previous values.

This can cause problems - hence my preference for left to right.  Here's an example:

Imagine that you have a "big" knob, -big A or -big B, that has a big effect - e.g. swapping in a table of multiple settings.

And imagine that you have a small knob, -small x or -small y, that changesd a subsetting.

E.g.
        command -big A    => table[0] = A0, table[1] = A1, table[2] = A2...

        command -big B    => table[0] = B0, table[1] = B1, table[2] = B2...


        command -big A -big B  
               => the later B overrides the earlier A
               => table[0] = B0, table[1] = B1, table[2]=B2...

so far so good.

But imagine that -small changes only one entry.


        command -big A -small x  => table[0] = A0, table[1] = x, table[2] = A2...

        command -big B -small y  => table[0] = B0, table[1] = y, table[2] = B2...



Later -small may override earlier -small


        command -big A -small x -small y => table[0] = A0, table[1] = y, table[2] = A2...



But... should a later -big override an earlier -small? I think so:


        command -big A -small x  -big B
               => My preference
               => table[0] = B0, table[1] = B1, table[2] = B2...



But many getopts parsers instead do:


        command -big A -small x  -big B
               => if -small is processed after -big
               => table[0] = B0, table[1] = x, table[2] = B2...


or, worse, have -big override even earlier -smalls.


List valued knobs don't help much here. Short-sight.  Although I admit that I have occasionally use list valued knobs as a kluge when dealing with a non left to right argumernt parser.


---


Some knobs have side effects.  Some even create other knobs.  There needs to be a defined order of evaluation.  Left to right is as goos as any.


---


The problem with left to right is that it tends to imply that you are building a data structure as you parse the knobs.  Which sometimes means that a later knob may cause you to want to destroy a datastructure that was being built.