Implement global named options #1

New Issue

torque · 2023-09-01T23:45:55-06:00

torque commented

2023-09-01 23:45:55 -06:00

There's some scaffolding for this in place, but the main complexity lies in making it safe by detecting tag shadowing, i.e. preventing a subcommand from using the same option tag as a previously declared global. Right now, duplicate tags are incidentally handled by the compiler while constructing some intermediate objects for a given command.

I don't think this could be entirely accomplished at comptime without messing up the semantics for how parser interfaces are constructed and attached (this currently has to happen at runtime), but this can at least be a really obvious and immediate runtime failure.

Note that global options are inherently at odds with dynamically-created subcommands (for example the way that git subcommands can map to independent executables). However, they can be a nice feature for statically defined command line interfaces, so I think they're still a feature worth pursuing

There's some scaffolding for this in place, but the main complexity lies in making it safe by detecting tag shadowing, i.e. preventing a subcommand from using the same option tag as a previously declared global. Right now, duplicate tags are incidentally handled by the compiler while constructing some intermediate objects for a given command. I don't think this could be entirely accomplished at comptime without messing up the semantics for how parser interfaces are constructed and attached (this currently has to happen at runtime), but this can at least be a really obvious and immediate runtime failure. Note that global options are inherently at odds with dynamically-created subcommands (for example the way that git subcommands can map to independent executables). However, they can be a nice feature for statically defined command line interfaces, so I think they're still a feature worth pursuing

torque added this to the 0.1.0 milestone 2023-09-01 23:45:55 -06:00

torque added the

Kind/Feature

label 2023-09-01 23:45:55 -06:00

torque self-assigned this 2023-09-01 23:45:55 -06:00

torque referenced this issue

2023-11-12 13:29:13 -07:00

consider: forbid ordered arguments on commands with subcommands #9

torque commented

2024-10-10 19:39:27 -06:00

This should probably be made its own ticket, but dynamic subcommands could be handled by allowing the user to register an "unknown subcommand handler", i.e. a callback to be called if the user passes a subcommand that is not known. This would let the user decide if they want to exec another program, or try to compute the Levenshtein distance to known commands in case of a typo (like modern git does, for example, if you typo git puhs).

This would probably need to be incompatible with global options. On the other hand, being overly restrictive would disable valid use cases, so letting the user decide on how much foot-shooting should be involved may be more appropriate. A callback like this would also potentially require #9, in order to have reasonable semantics.

This should probably be made its own ticket, but dynamic subcommands could be handled by allowing the user to register an "unknown subcommand handler", i.e. a callback to be called if the user passes a subcommand that is not known. This would let the user decide if they want to exec another program, or try to compute the Levenshtein distance to known commands in case of a typo (like modern git does, for example, if you typo `git puhs`). This would probably need to be incompatible with global options. On the other hand, being overly restrictive would disable valid use cases, so letting the user decide on how much foot-shooting should be involved may be more appropriate. A callback like this would also potentially require #9, in order to have reasonable semantics.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: factotum/NOCLIP#1