[Pharo-project] Command Line Handling
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... * The current implementation chooses the single matching handler with the highest priority, but usually command line tools may have multiple non-conflicting flags * 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). Maybe a registry would be better? A dictionary could just map flags to handlers e.g. -e -> EvalHandler, --evaluate -> EvalHandler, etc. Sean -- View this message in context: http://forum.world.st/Command-Line-Handling-tp4612779.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.
Thanks for helping me think this through, Camillo... Camillo Bruni-3 wrote
you conceptionally execute subcommands
Okay, I think I understand your intention better now. I was thinking of options, like "-la" for "ls", but you're talking about different modes, like you would never pass both a script and string, mixing basic code loader and eval... Camillo Bruni-3 wrote
* 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). ... and I disagree with you that it adds complexity. Just look at how much simpler...
I didn't mean that it increased complexity from the mess that you cleaned up :) Just that it may add unnecessary complexity to your simple system. I guess some real world use will reveal whether that's true... Re registry vs. select... if I'm adding a handler that will mask another handler, it seems like that'd be important to know, not to have it happen silently. I'm wondering whether the criteria-based approach adds unneeded flexibility at the cost of making the system less understandable. With a registry, you can have ifPresent: etc... Sean -- View this message in context: http://forum.world.st/Command-Line-Handling-tp4612779p4613781.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 2012-05-07, at 02:20, Sean P. DeNigris wrote:
Thanks for helping me think this through, Camillo...
Camillo Bruni-3 wrote
you conceptionally execute subcommands
Okay, I think I understand your intention better now. I was thinking of options, like "-la" for "ls", but you're talking about different modes, like you would never pass both a script and string, mixing basic code loader and eval...
exactly :) the goal was to go really in the direction of having separate subcommands (and right now with a minimal infrastructure). => maybe we should extend the class comments then to make this point clearer...
Camillo Bruni-3 wrote
* 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). ... and I disagree with you that it adds complexity. Just look at how much simpler...
I didn't mean that it increased complexity from the mess that you cleaned up :) Just that it may add unnecessary complexity to your simple system. I guess some real world use will reveal whether that's true...
true :) so far I saw that it massively simplified the test cases, plus coral. in coral there used to be an issue withe the default handler interfering, which was not the case in the new implementation
Re registry vs. select... if I'm adding a handler that will mask another handler, it seems like that'd be important to know, not to have it happen silently. I'm wondering whether the criteria-based approach adds unneeded flexibility at the cost of making the system less understandable. With a registry, you can have ifPresent: etc...
true, the override case is not properly handled I guess. however it is very easy to see what is registered in which way since everything is placed on the classes themselves. this avoids IMO to go and really inspect what has been put in the registry before (with all its condition blocks). my idea was: - you can always use the full class name as unique subcommand identifier - if you get a masking problem you can always add another handler which resolves this. - an easy way from the command line to see what is going on - list all active handlers - list all handlers for a certain input string - by using a real option parser and a decent default implementation you can resolve masking issues early on as you might figured out, my general assumption is that there are hardly any masking issues. this of course is very optimistic guess :P but since there are basically no cli applications out there in smalltalk it holds â so far :). best cami
participants (2)
-
Camillo Bruni -
Sean P. DeNigris