groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniil Ovchinnikov <daniil.ovchinni...@jetbrains.com>
Subject Re: About the enhanced version of `Properties`, i.e. `GProperties`
Date Wed, 07 Nov 2018 10:44:36 GMT
> 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 <tibokruse@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 <sunlan@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


Mime
View raw message