jxsl13 / simple-configo Goto Github PK

these function MUST NOT evaluate the action condition upon the call of actions.IfAction, but when calling the returned function.
This is a bug that causes incorrect behavior

• Load file content to string
• Load json file content to interface
• Load yaml file content into struct

A mutex may be locked before the PreParseAction, during the ParseFunction until after the PostParseAction

That same mutex may also be locked for the unparsing process where values are serialized back into a string map.

The sync.Locker is to be used and in case of nil nothing is locked.

add a parser to parse subconfigs, unparse them and write them to a file.

well, we seem to have the basic idea, but not yet a functional package!

In order to remove the parameter IsPseudoOption
wich is basically an option that executes the ParserFunction butbdoes not evaluate the default value nor does it use the value passed tobthe ParseFunc thus making the string value argument of the ParseFunc obsolete.

The next refactoring should remove IsPseudoOption and introduce multiple action parameters.
An Action ActionFunc is a function that does not take any arguments but returns an error.

We want a PreParseAction, a PostParseAction and a PreUnparseAction.

An option not containing a ParseFunction nor an UnparseFunction and at least one Action function is called an action.

An option struct containing either of ParseFunction or UnparseFunction of both is called an option.
These are explicitly associated with a config variable in your config struct.

Actions may also be associated with a config variable but they do not parse the key value env map provided at the time of parsing a configiration.

You might want to have configuration parameters saved back into a file once your application closes, thus it might make sense to introduce a secondary ParseFunc which has the same signature as the ParseFunc but is explicitly a

• SaveFunc

defer configo.Save(cfg)

https://medium.com/golangspec/tags-in-golang-3e5db0b8ef3e

might be worth a thought.

Current problem: You loose flexibility and features like the usage of previously parsed values like a delimiter in the following option parsing step.

nil evaluates to an error

The type field is kind of not necessary, as the ParseFunc handles all of the type specific logic.

Review the collision between default and mandatory values again.

A default value should only be checked when:

• mandatory=false
• mandatory=true&&defaultValue!=""

e.g.

parsers.Or(ParseFunc, ParseFunc, ...) error
parsers And(...) error
parsers.Xor(...) error