consider: forbid ordered arguments on commands with subcommands #9

New Issue

torque · 2023-11-12T13:25:49-07:00

torque commented

2023-11-12 13:25:49 -07:00

This has not already been implemented due to "maybe it would be useful in a weird scenario", but the more I think about it, the more I think it is a bad idea that permits the creation of confusing command lines. One of the goals of NOCLIP is to, while providing a lot of flexibility, encourage the creation of consistent and coherent command line interfaces across applications.

Optional ordered arguments can especially violate the principle of least astonishment here. In short, I can't think of any use cases that actually benefit from having ordered arguments preceding a subcommand.

From an implementation perspective, since subcommands are frequently added at runtime as type-erased interfaces to other type-erased interfaces, achieving this logic at compile time will probably be a bit messy. I don't see an immediately obvious implementation path at the moment. This may have to be a blatant runtime check, like the global option check in #1 would have to be, and that might be an argument against implementing it.

This has not already been implemented due to "maybe it would be useful in a weird scenario", but the more I think about it, the more I think it is a bad idea that permits the creation of confusing command lines. One of the goals of NOCLIP is to, while providing a lot of flexibility, encourage the creation of consistent and coherent command line interfaces across applications. Optional ordered arguments can especially violate the principle of least astonishment here. In short, I can't think of any use cases that actually benefit from having ordered arguments preceding a subcommand. From an implementation perspective, since subcommands are frequently added at runtime as type-erased interfaces to other type-erased interfaces, achieving this logic at compile time will probably be a bit messy. I don't see an immediately obvious implementation path at the moment. This may have to be a blatant runtime check, like the global option check in #1 would have to be, and that might be an argument against implementing it.

torque added this to the 0.1.0 milestone 2023-11-12 13:25:49 -07:00

torque added the

Kind/Enhancement

label 2023-11-12 13:25:49 -07:00

torque self-assigned this 2023-11-12 13:25:49 -07:00

torque commented

2023-11-12 17:50:08 -07:00

One possible option for making this compile-time behavior would be to remove addSubcommand from the parser interface and add a method to the generic parser instance to easily get a heap-allocated copy for longevity. This way all subcommands would have to be added to the generic parser before it is turned into an interface. Since the generic parser holds an arena allocator, it can trivially allocate itself.

This sounds like it would give the ability to add additional compile-time checks without having a big negative impact on API ergonomics, which I think would be a net win, even though it would make things slightly clunkier.

This would make it harder to dynamically add subcommands outside of the scope in which the root parser is defined, but that's not really a planned use case, and goes somewhat against the declarative, localized style of the API anyway.

One possible option for making this compile-time behavior would be to remove `addSubcommand` from the parser interface and add a method to the generic parser instance to easily get a heap-allocated copy for longevity. This way all subcommands would have to be added to the generic parser before it is turned into an interface. Since the generic parser holds an arena allocator, it can trivially allocate itself. This sounds like it would give the ability to add additional compile-time checks without having a big negative impact on API ergonomics, which I think would be a net win, even though it would make things slightly clunkier. This would make it harder to dynamically add subcommands outside of the scope in which the root parser is defined, but that's not really a planned use case, and goes somewhat against the declarative, localized style of the API anyway.

torque referenced this issue

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

Implement global named options #1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: factotum/NOCLIP#9