Lestropie
commented
6 months ago Another aspect that is probably closely enough related to this to warrant grouping them together rather than listing a separate Issue:
Currently, .type_choice() is treated as a distinct entry in the list of possible types, with the elements to choose from being a list of strings. This assumes that the only situation in which one might want to restrict the user to selecting one from a distinct set of possibilities is if that set of possibilities are of text form. Hypothetically, the presence or absence of a finite set of permissible inputs is not limited to arguments of text form. Instead, these current usages could be considered as both being of text form and having a finite set of permissible values. In conceiving of the operation in this way, arguments of type other than text could also have a finite set of permissible values, where the elements of that set have the same type as the argument. So eg. some integer input may not just be restricted to minimum and maximum values, but be forced to be one from some set of permissible integer values; but the type of that argument should still be integer, whereas currently achieving this using .type_choice() kind of forces them to be of text type, with subsequent explicit conversion to integer after command-line parsing.
There are now a number of commands where the user's input for a particular argument could be interpreted by the command in multiple ways; eg. a transform could be a text file with an affine transformation or a warp image, or a set of directions on the unit hemisphere could come from a text file or an image header. To support these cases, we're added the "
.type_various()" classification, such that any special handling within the command-line parsing is effectively bypassed. This will also appear in some cases where the command-line interface is exported to text.What would be a more targeted solution is to allow each argument to receive multiple classifications. So eg. in the examples above, the argument would be classified as being compatible with either an input file or an input image, but not anything else. Any command-line interpretation cleverness would then be compatible with the user providing either of those cases. And exported command-line interface information would more faithfully communicate what is and is not permitted for that argument.
Not sure how much benefit could actually be gained from such---probably not much---but I wanted to document it in case it may be recognised as the solution to some issue.