…-framework

…-framework

…framework

…-framework

This change adds:
* A `config.Walk` function to walk a configuration tree
* A `config.Path` type to represent a value's path inside a tree
* Functions to create a `config.Path` from a string, or convert one to a string

…-framework

The name "dynamic value", or "dyn" for short, is more descriptive than the
opaque "config". Also, it conveniently does not alias with other packages in
the repository, or (popular ones) elsewhere.

The code relied on the `Name` property being accessible for every resource.
This is generally true, but because these property structs are embedded as
pointer, they can be nil. This is also why the tests had to initialize the
embedded struct to pass. This changes the approach to use the keys from the
resource map instead, so that we no longer rely on the non-nil embedded struct.

Note: we should evaluate whether we should turn these into values instead of
pointers. I don't recall if we get value from them being pointers.

…g-framework

…-framework

…-framework

This change adds the following functions:
* `dyn.Get(value, "foo.bar") -> (dyn.Value, error)`
* `dyn.Set(value, "foo.bar", newValue) -> (dyn.Value, error)`
* `dyn.Map(value, "foo.bar", func) -> (dyn.Value, error)`

And equivalent functions that take a previously constructed `dyn.Path`:
* `dyn.GetByPath(value, dyn.Path) -> (dyn.Value, error)`
* `dyn.SetByPath(value, dyn.Path, newValue) -> (dyn.Value, error)`
* `dyn.MapByPath(value, dyn.Path, func) -> (dyn.Value, error)`

Whenever the "set" and "map" functions need to change a value, they return
a new `dyn.Value` such that the input value is never changed.

This is the `dyn` counterpart to the `bundle/config/interpolation` package.

It relies on the paths in `${foo.bar}` being valid `dyn.Path` instances. It
leverages `dyn.Walk` to get a complete picture of all variable references and
uses `dyn.Get` to retrieve values pointed to by variable references.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch dynvar
# Changes to be committed:
#	new file:   libs/dyn/dynvar/lookup.go
#	new file:   libs/dyn/dynvar/lookup_test.go
#	new file:   libs/dyn/dynvar/ref.go
#	new file:   libs/dyn/dynvar/ref_test.go
#	new file:   libs/dyn/dynvar/resolve.go
#	new file:   libs/dyn/dynvar/resolve_test.go
#
# Untracked files:
#	extra/
#

References to keys that themselves are also variable references were
shortcircuited in the previous approach. This meant that certain fields were
resolved even if the lookup function would have instructed to skip resolution.

To fix this we separate memoization of resolved variable references from
memoization of lookups. Now, every variable reference is passed through the
lookup function.