It would be nice to extend the current approach to settings layering ('closest' overrides) to allow driver authors to define alternate behaviour when duplicate keys exist. This enable configurations that use deep object merges, list concatenation, min/max and other binary operations across layers to form the final output.
A good reference for this is the NixOS module types: https://nixos.org/manual/nixos/stable/index.html#sec-option-types-custom.
Previous approach: acaprojects/ruby-engine#16.
The implementation above allowed merge behaviour to be specified on access. Implementation here may be better suited to declaring this as part of a setting definition. This will ensure that any external systems providing a merged view (e.g. PlaceOS/backoffice#165) also apply the same behaviour as well as providing the ability to cache outputs following first access.
It would be nice to extend the current approach to settings layering ('closest' overrides) to allow driver authors to define alternate behaviour when duplicate keys exist. This enable configurations that use deep object merges, list concatenation, min/max and other binary operations across layers to form the final output.
A good reference for this is the NixOS module types: https://nixos.org/manual/nixos/stable/index.html#sec-option-types-custom.
Previous approach: acaprojects/ruby-engine#16.
The implementation above allowed merge behaviour to be specified on access. Implementation here may be better suited to declaring this as part of a setting definition. This will ensure that any external systems providing a merged view (e.g. PlaceOS/backoffice#165) also apply the same behaviour as well as providing the ability to cache outputs following first access.