composition

[thejohnfreeman]

Compositions of configurations should be defined independent of the sources of those configurations.

Let us define a composition operator for configurations: override. override takes two configurations, top and bottom, and returns a new configuration with a union of every variable in the two configurations with the values from top taking precedence. In general, clients will start with a configuration of defaults and apply a sequence of overrides.

override may optionally throw, warn, or ignore overrides that do not exist in bottom. Ignore is a good option for migrating configurations across client versions. If a client updates from version 1 to 2 and drops configuration variable "x", a good migration tool will silently drop overrides of "x" in old configurations. Warn and throw are good for clients of varying pedantry.

override may optionally type check overrides. Some clients may want to delay validation until use, to avoid validating unused variables. Some may want pedantic validation of all overrides.

[sampsyo]

Yes, composition seems essential. In the current Confit, this works using mutation: RootConfig.add() pushes a bottom data source onto a stack, and RootConfig.set() puts a top on the opposite end of the list.

About validation: It seems like it would be useful to keep composition and validation separate, right? I don't see a particular need to couple the two conceptually. (Of course, an API call that does both at once could definitely be useful for cosmetic reasons.)

[thejohnfreeman]

You're right, it will be good to keep them separate. We can always compose them into a single function for convenience.