Command parsing limitations

[Jack Greenberg]

The parsing functionality provided by the command and types packages currently has several major limitations that should be addressed:

• Repeated flags (ex. -vvv for verbosity level) are not supported, and are currently collapsed into one.
• Flags that are not at the beginning of the command are treated as generic arguments.
• Flags without values are represented as BoolValue{ V: true }, which is indistinguishable from a flag with an explicit boolean value. This causes trouble for converting the flags back to arguments when calling or serializing a command.
• If parseOptions.assumeOptionArguments is true, a flag with no value can steal the first positional argument. Since flags are not stored in any particular order, this makes it possible that the argument will become mixed in with other flags instead of being placed back in its old position.
• --flag=value is not supported.
• A command.Command currently cannot be serialized back into a string equivalent to the one it was parsed from, for many of the reasons listed above. This is worked around with command.Command.Original, but this is fragile and assigned in odd places at different levels of the system.
• Command equality testing is currently not implemented.
• command.Command and data.CommandEntry have a cyclical dependency, where a Command is needed to get e CommandEntry from the data access layer, but the CommandEntry then contains parse options that are used to re-parse the Command.

It would probably be advantageous to come up with design changes or a redesign that hits all of these at once.