Hi sean, thanks for the response... though I'll be mostly standing against your observations here :). On 2012-05-06, at 14:41, Sean P. DeNigris wrote:
I've played a lot with the new command line argument handling. Here's a few thoughts: * I think we should not allow the use of raw handler names (e.g. 'eval') and restrict ourselves to flags. For example, disallow 'eval' and stick to '-e' or '--evaluate'. The raw name introduces ambiguity in parsing the command line, especially since custom commands can be added at will that may conflict and see next item...
there is no ambiguity, since you can always push a command further up by changing it's priority. besides adding switching is not that nice since you conceptionally execute subcommands
* The current implementation chooses the single matching handler with the highest priority, but usually command line tools may have multiple non-conflicting flags
I disagree with that. AFAIK there is no unix tool that does that. The only way that this happens is for subcommands that may inherit from their parents some options (see all git sub commands that still allow for --repository from the main command). If you want to support multiple ones you can still add a specific handler that will merge your N other handlers.
* The priority concept seems premature. It adds complexity and confusion (the handler for a specific flag is not obvious because it emerges from an interaction of all the handlers).
1. the input is given to all handlers which decide whether they can do something with it or not. 2. the handler with the highest priority is chosen
Maybe a registry would be better? A dictionary could just map flags to handlers e.g. -e -> EvalHandler, --evaluate -> EvalHandler, etc.
again, I want to have subcommands, and not some smalltalk specific handling... (like for instance the super weird -LONGOPTIONNAME from the vm...) and I disagree with you that it adds complexity. Just look at how much simpler the tests are now, the system doesn't work globally any more. or for instance for coral... I didn't have to manually unregister the default option anymore. In my optinion the system got much easier to use. Of course the goal would be to use some option parsing mechanisms from coral. but I think the base system should be rather flexible and very small and simple.