Skip to content

Removing main side effects from public interface (Parser type) #59

Closed
@gsscoder

Description

@gsscoder

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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions