At present, we don't make a file() include relative to the
file doing the including. This is discussed in #202.
We should most likely change this behavior, but this
commit documents and tests it.
Fixes#212 that object and list substitutions could not have
whitespace in between.
This patch carries quoted-ness into ConfigString, which is somewhat
bogus, and we may be able to clean it up later if we start to track
the tokens that each value originates from.
This is a spec change but the spec was wrong and the implementation
previously just threw an exception.
The spec claimed that ${?foo}${?bar} would become empty string,
but it's more useful for it to just become undefined.
You can add an explicit empty string with "" if you want it
to be empty string.
Fixes#161.
Previously, a string which was an invalid number (such as
"1.0.0" or "1e3e3") but consisted entirely of chars allowed
in numbers would be an error and require quoting. Now, we
allow such strings to be unquoted.
path : [ /bin ]
path : ${path} [ /usr/bin ]
This added very few lines of code or bytecode!
It's just a natural extension of the existing
string concatenation.
But it did add a fair few lines of specification
and tests.
With this patch, you can write:
path="a🅱️c"
path=${path}":d"
The semantics are somewhat complicated to specify and
implement, but hopefully not complicated to use for
any reasonable usage that makes any sense.
This patch is technically backward incompatible,
illustrated by a change to existing unit tests,
but the changed behavior is in a bizarre corner case:
cyclical self-references where the cycle could be broken
by only partially resolving an object.
This corner case just threw an exception in the version
of this lib included with Akka/Play 2.0, but in commit
a59e31f744 we tried to handle the case. So the behavior
changes since that commit.
The partial resolution case now has the same consistent
defined semantics we use for all self-reference
resolution, that is it "looks back." In the previous
code it would "look forward."
The broken behavior was:
foo=10
foo=${?bar}
where 'foo' should be 10 if bar is undefined, but instead
ended up undefined. Now, foo will be 10 (which was the
documented behavior).
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.
