Thanks to visit codestin.com
Credit goes to GitHub.com

Skip to content

Command parsing limitations #225

@grebneerg

Description

@grebneerg

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions