Description
As you seen with latest release a lot was done to simplify the library.
Don't get me wrong, I'll not change basic concepts of the API; but I'd like to embrace good design from functional world for make our library strongest.
When you declare the options type:
var options = new Options();
options
is in state X (initialized) and after
var result = new Parser().ParseArguments(args, options);
options
is in state Y (with parsed values)
So we can say that ParseArguments
caused side effects. Another one, is the result (also influenced by the same function... opssss method!).
Incredibly the solution is quite easy:
T Parser.ParseArguments<T>(string[] args, Action onFail)
The method with this new signature constructs the instance and returns it.
- If parsing succeed, the instance is loaded with parsed values.
- If parsing fails and
ParserStateAttribute
is used, the generic errors list will be available as always.
But if parsing fails an appropriate delegate (Action onFail
) is called.
Other advantages: convergence of standard methods with strict methods (@nemec suggested feature).
Functional paradigms proves their effectiveness from '70 (and before), please dig into the argument if not convinced. :))
As always, opinions (or flames) are welcome.
PS:
Some side effects for the moment will remain. E.g.: printing out the help. As said, I'm moving to a removing the most evident of these.