I have recently been working with expanded defaults (for example, defaulting a directory path to a generated subdirectory of a temp directory. In grades that extend the base grade, I usually want to replace the expanded material with literal options. This led me to discover a few oddities. Take a look at this example:

There may be a very real reason for the base grade to "win" during the expansion and merging process, but the net effect is a bit confusing:

1. Expanded options from a base grade are simply replaced if they represent a literal value.
2. Expanded options from a base grade are not replaced if they are objects or arrays.
3. IoC references can be used to replace the underlying expanded options.

If this is the intended behaviour, it should be better explained with an example in the expansion and/or merge policy docs. For example:

By default if there is no policy specified, a deep merge is done together with expansion. Firstly, any IoC references and expanders in the source objects will be expanded. Secondly, everything in the source objects are copied over the target object, in a manner very similar to the operation of the jQuery API method $.extend(true, ...). Anything that existed in the target but was not present in any of the source objects will continue to be present in the resulting merged object.

On reading this, I would expect the base grade's options to have been expanded, and then merged with the child grade's options, including resolving IoC references, such that in both child grades options.expanded.object would be:

The inconsistencies can be mitigated somewhat using merge policies for expanded options, i.e. you can specific a merge policy of "nomerge" that will ensure the "child" grade's options will be used. However, this does not cover the case above, in which we wish to inherit generated options and merge them with individual options of our choosing.

cc: