The earlier change to make ${user.home} in a file included underneath
"foo" search both ${foo.user.home} and then ${user.home}, means
that even in included files system props are picked up just fine
as long as they were merged into the root config. So there is no
longer any need to have a special-case fallback to system properties.
This leaves ConfigResolveOptions as a really complex way to pass
in a single bool, but of course the point is to allow for future
extension.
This should lay the groundwork for removing the special case fallback
to system properties, and allows included files to look at the reference
configuration.
currently needed for files that are included in other files.
not really happy with how this works now, but documenting it
as a starting point.
maybe to force a substitution to resolve from the root we could
start it with a period? ${.this.is.a.root.prop} ?
Also updated the spec; in this patch, the spec says ${?missing} will be
undefined, but the code still evaluates it to null as in the old
behavior. A follow-up patch will introduce the undefined behavior
that is now specified.
This change is needed because missing substitutions are probably
a problem in most cases, and evaluating missing to null is probably
not as useful as evaluating it to undefined. If it turns out that
we need the null behavior, a possible syntax is ${foo.bar,null}
or something like that.
The general idea here is to permit future syntax extensions;
as a rule, new syntax can only be added by using one of these
characters that can't be a string.
Backtick ` in particular is in the current ECMAScript drafts
for multiline strings, so supporting multiline strings with
that would be a very natural thing to do.
The other characters added here (^, !, ?, @, *, &) are
more or less arbitrary. &, ! and * have special meaning
in YAML so might be natural ones to use for similar
purposes. ? would have some natural "let this be missing"
meaning, @ is often used in template-like things, and ^
could be used for some unforeseen need.
The spec described parsing this as a 1-element path but
the implementation parsed it as 2 elements which is probably
a better behavior because it's less surprising. The simple
rule is now "only quoted periods are special".
The AbstractConfigObject.merge() method was wrong; it merged in the
wrong order, which produced incorrect results. But there was a test
verifying that the results were wrong! So it's OK right?
Anyway, fix the test, fix the code, be sure it's crystal clear in spec.
