Actually, I don't really see the regex approach ever reaching maturity
for evaluation expressions. Just the simple property "foo=${'}'}" and
its variants are probably impossible to handle with regexes, (because
finding the the end of a groovy expression without a parser s hard).
An actual Parser would be required, so I guess an approach would have
to put the property value in quotes (escaping existing quote-ending
quotes in the middle) and try to evaluate it as a Groovy script or
something similarly complex. Not sure if anyone wants to go there.If not, that would leave importing and interpolation, but as I said there is already an apache commons project doing exactly that, so reusing it instead of reinventing wheels may be the better approach, if this kind of feature should be offered by Groovy. On Sat, Nov 3, 2018 at 11:30 PM Thibault Kruse <tibokr...@googlemail.com> wrote: > > Hi all, > > thanks Daniel for making the suggestion and PR. > > BTW there already is an extension in > http://commons.apache.org/proper/commons-configuration/userguide/howto_properties.html#Using_PropertiesConfiguration > including a syntax to include other properties files, to be considered > (though that one allows duplicate keys, apparently), also it uses the > ${} syntax to load environment variables, also considered a useful > concept for property files by some people. See > https://www.javacodegeeks.com/2015/04/a-way-to-read-properties-with-variable-interpolation.html > > I am also sceptical about adding this to groovy core to handle properties > files. > > First let's document the specification of the idea: What you suggest > is a solution that loads a property file using the JVM Properties > class, and then on lookup of keys, loads the value as usual, but then > applies some interpolations of marked substrings. > > I feel as a specification this is not precise enough, and I am not > sure which behaviors of the PR are intended and which ones are > accidental (see my review comments below). > > For usability my concern is that when wrapping value lookup by > GProperties, a human reader cannot see that in the properties file, > and so users are left confused as to what happens to any given > properties file. A program could use Properties for one x.properties > file, GProperties for y.properties file, and users of an application > or library can only find out by trial and error which one is used for > which. > If any application or library replaced Properties with GProperties, I > believe the results may be disastrous, because upgrading users would > face any number of runtime exceptions due to new semantics of their > values. It seems there is no backwards compatible upgrade path that > guarantees to users that whatever values they have in the properties > ile, switching to GProperties will maintain those values. Just as a > brainstroming example: if only properties written such as "foo ~= {x}" > would be interpolated, that would be a safe upgrade path (but I > realize the coding would not be as simple as the current PR). > > There are also several edge and error cases currently not considered > in the PR, not sure if the PR is just meant as a prototype, but let me > list what I can think of so far: > * infinite cycles in the importing of other properties > * if a properties file imports another one, should the other one be > loaded as Properties file or as GProperties file? Can the user decide? > (the other file may come from a different jar outside the control of > the user). > * infinite cycles in the interpolation of variables > * multiple interpolation when the substitution of a substring contains > a pattern to be interpolated by itself: a=1; b={a}; c=${'{b}'} > * nested interpolations "{foo${key}}" > * unbalanced parentheses '{{key}' > * if we have > # parent.properties > other=parent-other > takeother={other} > > # child.properties > import.properties=parent.properties > other=child-other > local={takeother} > > Which value will get(takeOther) in child.properties produce, and which > should it produce? What if we involve more files with import > relationships? Suddenly invisible links start creeping up between all > imports. > > > Some of the problems with the PR may be solvable (such as by using a > single Regex instead of three consecutive ones), but a lot more > test-cases are required, and the semantics of the import statement > remain quite complicated to maintain, and for users to debug. Before > including, I feel much more edge and error case testing should be done > and a more precise specification should be written first. > > I don't want to generally discourage the idea, I hope my comments can > help others come up with more concerns, ideas or alternatives.
