groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: About the enhanced version of `Properties`, i.e. `GProperties`
Date Wed, 07 Nov 2018 19:45:36 GMT
I agree with Daniil.

@xml: In that case OpenOffice and MS Office documents should just have 
the extension .xml.zip since they are just zipped XML files.
While it is correct that one can discern the type of XML dialect used in 
an XML file from its header, for many applications it is still 
convenient to be able to discern it through an extension.
If one wants to keep the number of newly introduced file extensions to a 
minimum, .xml.gproperties could be an option...

Cheers,
mg


Am 07.11.2018 um 11:44 schrieb Daniil Ovchinnikov:
>> 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 
>> <mailto: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 
>> <mailto: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