> 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> 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> 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
