You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An annoying byproduct of the current parse-options implementation is the need for validation after the argument list has been parsed. For instance, some options might only apply to certain subcommands, so the caller needs to check that all of the result values are correct and make sense.
I've been recently trying to think of ways that we could improve this, grouping option specs in a more hierarchical manner. If we can organize our options specs in that way, we might be able to handle automated argument validation and printing usage strings.
The basic idea will be to introduce a new structure that accepts a top-level option (which could be a subcommand or any type of option), and arrays of sub-options. An implementation might look like this:
An annoying byproduct of the current parse-options implementation is the need for validation after the argument list has been parsed. For instance, some options might only apply to certain subcommands, so the caller needs to check that all of the result values are correct and make sense.
I've been recently trying to think of ways that we could improve this, grouping option specs in a more hierarchical manner. If we can organize our options specs in that way, we might be able to handle automated argument validation and printing usage strings.
The basic idea will be to introduce a new structure that accepts a top-level option (which could be a subcommand or any type of option), and arrays of sub-options. An implementation might look like this:
One hard requirement is to stick to static allocation. This will help ensure that the solution is clean and not prone to memory leaks.
The text was updated successfully, but these errors were encountered: