The GProperties language is the same language or a subset of the
Properties language
which doesn’t mean that same extension should be used, see example
with .java/.groovy.
Even with standard Properties, users are free to add keys for
interpolation to their values, or add SQL statements as values, none
of that requires a change of file Extension
which still doesn’t mean that same extension should be used.
Special IDE support is not required, whatever support an IDE offers
for standard Property files also works fine for GProperties
I guarantee users will want essential features:
- navigate from interpolation to the property;
- find usages of a property;
- rename a property and expect its usages in other properties to be
updated.
None of Commons-Configuration,
Archaius(https://github.com/Netflix/archaius) or even ResourceBundle
(https://www.mscharhag.com/java/resource-bundle-single-quote-escaping)
use a different file extension
commons-configuration is not supported because:
- there is not much demand because it is a third-party library;
- there is still no way to know if some property file is
commons-configuration property file;
- there is other non-declarative stuff which is basically
unsupportable at all.
Archaius is basically commons-configuration.
RB is a different mechanism, it is about external parameters for
properties, it’s not about using some property in the interpolation.
Properties also support loadFromXml(), and I guess nobody wants to
suggest using .gxml as different extension?
That is a good point.
Observation: xml properties file is expected to use specified doctype
which makes is distinguishable from other xml files.
If GProperties is a subclass of Properties then is either should
provide a way to distinguish gproperties from regular xml properties
or throw exception in loadFromXml/storeToXML.
—
Daniil Ovchinnikov
JetBrains
On 7 Nov 2018, at 03:13, Thibault Kruse <tibokr...@googlemail.com
<mailto:tibokr...@googlemail.com>> wrote:
I propose to use "gproperties" as file extension.
'.properties' is the correct file extension for GProperties. There are
several reasons:
* The GProperties language is the same language or a subset of the
Properties language
* Even with standard Properties, users are free to add keys for
interpolation to their values, or add SQL statements as values, none
of that requires a change of file Extension
* Special IDE support is not required, whatever support an IDE offers
for standard Property files also works fine for GProperties
* None of Commons-Configuration,
Archaius(https://github.com/Netflix/archaius) or even ResourceBundle
(https://www.mscharhag.com/java/resource-bundle-single-quote-escaping)
use a different file extension
* Properties also support loadFromXml(), and I guess nobody wants to
suggest using .gxml as different extension?
Some other concerns:
P.S. Unbalanced curlies will not be considered, because curlies are
valid characters for the value of property.
I don't understand what any of that means, but you can add a testcase
for locally unbalanced properties like this:
foo = Hello {{{name1} and {name2}}}
to your testcases.
Also, I believe the key of properties files can also contain special
characters, so these are also valid keys:
{ = leftcurly
} = rightcurly
{{ = mustache
{} = ufo
So in GProperties it should be possible to reference them, like
uforef = {{{}}}
Yeah, not really. To properly reference those you'd need a way to
better mark the start of an interpolation key (such as ${}), and a way
to escape the interpolation end symbol inside an interpolation key. At
this time I believe you can pretty much forget about regular
expressions, and start writing a traditional Character-by-Character
parser for GProperties.
Another unrelated topic is whether and how to combine importing and
interpolation. As an example:
import.properties = application-{profile}.properties
I think the latest version of GProperties would not interpolate that,
not sure if intentionally or by mistake (since resolving the key
against imports would be tough during importing). This is related to
the next concern.
Similarly, a question is whether interpolation may use values from
imported files. As an example:
import.properties = ~/.access_secrets.properties
window.title = {db.username} logs in with {db.password}
I believe the implication for security should be obvious.
Finally, for backwards compatibility:
Commons-configuration also has the typesafe accessors (getLong(),
getString(), getInt()...) which do variable interpolation. But
getProperty() actually returns the raw, non-interpolated String from
the properties. That might be a good idea for GProperties, too (for
backwards compatibility but also for other purposes, such as
debugging).
On Tue, Nov 6, 2018 at 8:40 PM Daniel.Sun <sun...@apache.org
<mailto:sun...@apache.org>> wrote:
Understood.
I propose to use "gproperties" as file extension.
Cheers,
Daniel.Sun
-----
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
