Bug and Design Flaw: Option "--opts" clashes with Command#opts function

[mwittig]

I think it is a major weakness of the commander design that the parse result is simply added to the Command object which itself contains functions members like opts(). This way, it will not be possible to use an option like

program.options("--opts [value]", "Decription");

as the parse result, i.e., "program.opts" does not refer to the option value but to the opts function of the Command object.

Possible solutions:

1. Let Command contain an result object where parse results are stored.
   or
2. Rename Command functions to be less harmful, e.g. use underscore prefix

Well, there may also be other solutions. Please also advise if the there is a better way of using the API. I have just followed the given examples to familarize myself with the commander API.

[SomeKittens]

This is a known issue, and a big one. Unfortunately, us maintainers are all volunteers and don't have the free time we'd like to fix things. We're working on a plugin system but that's a long time coming.

[mwittig]

I am happy to help on the project, but I don't understand why you close the issue as it has not been solved. As there some, similar issues raised why don't you group than as one Bug issue?

[onury]

This is not right. You should keep this open if it's not resolved.

[shadowspawn]

Added to triage item: #933
There is a work-around now: program.storeOptionsAsProperties(false)