Two properties for parsed options?

[shadowspawn]

The current description has two properties for identified options, and an option with a value appears in both:

args {Object}, having properties and Boolean values corresponding to parsed options passed
values {Object}, have properties and String values corresponding to parsed options passed

I found this a bit unexpected, and unlike what I see in other implementations (Commander, Yargs, et al).

If this a deliberate design decision? I didn't find any discussion that led to this, and don't want to go too deep on commentary if it is a somewhat accidental iteration as functionality has been added!

[bcoe]

@shadowspawn If I recall, one of the reason for the two return values, was so that you could differentiate between the case where an option was passed no argument, vs., an option not being set at all.

I think in practice someone would tend to use either args or values, but someone building a more copmlex command line application on top of the parser would be able to look at values vs., `args, and infer more information about what the user provided.

[shadowspawn]

Thanks for recollections. Not convinced yet, but happy to wait and see! (How code develops, what gets stored, what client code looks like.)