> 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
