Add arguments to OptionAttribute so MutuallyExclusiveSet can be set

[palfrey]

Previously it appears to be nearly impossible to set mutuallyExclusiveSet, but I've added optional arguments to the OptionAttribute constructor so this is now possible.

[gsscoder]

Hi,
sorry but this is sounds a bit strange to me...

Why with default code base you can't set this attribute property?

Regards, Giacomo

[palfrey]

AFAIK (although if you've got a counter-example I'd love to see it), it's impossible to set properties on an attribute that takes arguments to it's constructor, hence the wish to add an argument to the constructor.

[alexanderfast]

I'm gonna jump in here and say that neither I have got the mutually exclusive stuff to work, I assume it's because I don't understand how they are supposed to be used.

This might boil down to simple confusion. That attribute doesn't have an example in the wiki. Perhaps one should be added?

[palfrey]

Yay... I've just figured what I was doing wrong. "PropertyName = Foo" works, "PropertyName: Foo" doesn't...

[palfrey]

Related to the mutually exclusive ones, I'm using it for a set of actions, and the program can only do one at a time, so that sounds like a good option for the wiki example.

[alexanderfast]

Actions? Is that what I refer to as verbs or commands? Have a look at #17.
Also, now that you've figured out the mutually exclusive property (I still haven't) could you add a short snippet to the wiki? :)

[nemec]

@palfrey Attributes do named parameters weirdly (I suppose it's because attributes were added before support for default parameters was added to the language). For a more complete explanation of the difference, check this out: http://msdn.microsoft.com/en-us/library/aa664614(v=vs.71).aspx

[gsscoder]

Sorry if I came late also to this thread.

To be honest the Mutually Exclusive stuff, as Alexander says, it was ever a bit controversial.

It is built around this concept: if I have one or more group of options that relates to each other but not with other groups, have I to write domain-specific logic each time? No, you should not!

Here come this feature. Let me explain better...

Suppose you have four options, say 'a', 'b', 'c' and 'd'.
Your app spec wants this:
'a' can't live with 'b'
'c' can't live with 'd'

So as you can see group are made of opposites. For accomplish this task you put opposites (hence mutually exclusive options) in the same group with the same group name (or set, or better MutuallyExclusiveSet).

class Options {
[Option('a', MutuallyExclusiveSet="set1")]
public bool SwitchA { get; set; }
[Option('b', MutuallyExclusiveSet="set1")]
public bool SwitchB { get; set; }

[Option('c', MutuallyExclusiveSet="set2")]
public bool SwitchC { get; set; }
[Option('d', MutuallyExclusiveSet="set2")]
public bool SwitchD { get; set; }
}

So this means that this is possible:
$ app -ac or $ app -b -c or $ app -da

but not this:
$ app -a -b or $ app -dc

See this unit test for reference (try to think to unit tests as additional documentation or documentation itself when it lacks!): https://github.com/gsscoder/commandline/blob/master/src/tests/Parser/MutuallyExclusiveParsingFixture.cs

Look also at least at one of the options class used by the fixture.:
https://github.com/gsscoder/commandline/blob/master/src/tests/Mocks/OptionsWithMultipleSet.cs

Is it now more clear?

Regards, Giacomo

PS: ASAP I'll update the wiki (also with verbs stuff).