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
