Same command in different subcommand

[svercl]

Hi, I have multiple sub-commands, and they have the same command name.

Snippet:

dispatchMultiGen(["foo"], [add])
dispatchMultiGen(["bar"], [add])
dispatchMulti([foo], [bar])

Which leads to the error: Error: overloaded 'dispatchadd' leads to ambiguous calls.

How would I go about having sub-commands with an identical name underneath them?

[c-blake]

We may also need to have the generated dispatcher name key off of the subcommand name. If your adds are not identical, you may also need test/SpecifiedOverload.nim tricks and it may also be necessary to be more careful to call the right thing in dispatchGen. Will have to look into this in about 8..12 hours.

[svercl]

I should be more specific. The command name will be the same by cmdName but they are different procs.
As in:

dispatchMultiGen(["foo"], [fooAdd, cmdName = "add"])
dispatchMultiGen(["bar"], [barAdd, cmdName = "add"])

Thank you for looking into this!

[svercl]

There is a workaround to set the dispatchName inside the Gen proc, but that is a little verbose. I feel it should be handled automatically.

[c-blake]

I think sticking with dispatchName / test/QualifiedMulti.nim / a bit more work by the CLauthor on this one is ok. I mean, this may have come up right away for your use case, but how often in general? test/MultiMulti.nim stuff is already quite manual and, I believe, also uncommon. This situation is 2nd order on that already uncommon manual situation.

Everyone is different, but as a CLuser I don't even like nested subcommand structures and there is precious little "standard" syntax. The times I see these deep trees they also seem to be narrow, like 2..4 forks at many levels. I would just have it be one level with fooAdd fooDel, etc. To me automation here eases use for CLauthors to make more common a situation CLusers already find tricky which may not be "encouraging the world in the right direction".

So, unless other people complain, it's hard for me to see this is an important issue. I kind of doubt this is even the most important automation in a Multi-Multi setting. All that said, I am an open-minded person. If you want to try a PR, you can.

[svercl]

I missed that test :) The reasoning for the nested sub-commands was simply because I am wanting to be compatible with the original work, instead of having a new CLI with new commands to remember.

[c-blake]

Yeah. I thought that might be the motivation. One of the original pushers for sub-sub/sub-sub-sub command type stuff was @xmonader who was trying to replicate Docker which I personally find very overboard along these lines. { And as much as Go has much mind share over Nim, I don't think some CLI toolkit for it or Docker's popularity exactly constitutes some new standard in multi-level sub-sub-sub-cmd type CLIs. }

So, replicating existing is still a pretty special edge case, perhaps being ok as manual as it is, but I am open-minded. I introduced that whole parseOnly/setByParse stuff for other such edge cases, but using it remains pretty manual. It's not always easy to automate every thing.

You may also be able to lessen repetition via some kind of template or macro embedded "on the inside" in your constructions.