Example: the engine may have a system-wide bgcolor prop, and so can the app, overriding it. Then, all the things that need a bg. color should obviously not be burdened with hunting for some legit value -- they should just ask their closest cfg buddy, as before, delegating any fallback traversal implicitly to the cfg provider itself!
[x] The biggest task of this is just to design the API to support both this and the legacy string defaults...
[x] New ctor? More complicated existing ctor? Any other extra method too? (The ctor still must cover this, to support all the sad C++ ctor init lists...)
Ugh, the existing ctor just could still bear this new param., fortunately... (A little awkward, if not needed, it may need to be set to nullptr explicitly, and it -- therefore -- is also a pointer now, but... I can live with that.)
[x] A crude, embryonic version of this is kinda implicitly developing inside OONConfig already, in that it has a SimAppConfig reference from its inception -- but it's not used for default-resolution yet. Go ahead with that explicitly then, and use it as a test-bed!
Example: the engine may have a system-wide
bgcolorprop, and so can the app, overriding it. Then, all the things that need a bg. color should obviously not be burdened with hunting for some legit value -- they should just ask their closest cfg buddy, as before, delegating any fallback traversal implicitly to the cfg provider itself![x] The biggest task of this is just to design the API to support both this and the legacy
string defaults...nullptrexplicitly, and it -- therefore -- is also a pointer now, but... I can live with that.)[x] A crude, embryonic version of this is kinda implicitly developing inside
OONConfigalready, in that it has aSimAppConfigreference from its inception -- but it's not used for default-resolution yet. Go ahead with that explicitly then, and use it as a test-bed!-> #401