I agree with this as well. It seems like a general improvement and I cannot
imagine a later date being better than now to get this change in.
Sent from a tiny keyboard
________________________________
From: Aaron Coburn <acob...@apache.org>
Sent: Monday, January 14, 2019 9:36:04 AM
To: dev@tamaya.incubator.apache.org
Subject: Re: API deprecation for ConfigOperator, ConfigQuery
I agree with ajs6f. Given that we're still pre-1.0, this is definitely the time
to make any API changes. I also think that reducing the API footprint is a good
direction to be going in.
That is, I would be in favor of keeping these API changes.
Aaron
> On Jan 13, 2019, at 4:35 PM, ajs6f <aj...@apache.org> wrote:
>
> We migrated some of this kind of type system to java.util.function.* for
> Apache Jena in the following way (I'll use ConfigOperator for the example):
>
> 1. Change all acceptor sites (params, ctor slots, wherever this type is being
> used) to use UnaryOperator<Configuration> and simultaneously
>
> 2. Deprecate ConfigOperator and make it extend UnaryOperator<Configuration>,
> with something like:
>
> default Configuration apply(Configuration c) {
> return operate(c);
> }
>
> Users needn't change anything right away, but they are being informed that
> they can simply use java.util.function.* instead. I was in favor of this for
> Jena (in fact I made many of the commits) because I think that in the long
> run, a smaller footprint with the same semantics is worth more than
> super-tight back-compatibility _if_ the community can handle the change.
> After another release or so, Tamaya could excise the old types entirely.
>
> Tamaya is still in incubation, and hasn't released 1.0. I think this is a
> good time to think long-term and make the API what it should be, even if us
> users have to tap-dance a bit to keep up. We'll all be better for it down the
> road.
>
> My 2ยข... unless, of course, I'm completely misunderstanding what you mean by
> "API incompatibilities", which is certainly possible.
>
> ajs6f
>
>> On Jan 13, 2019, at 3:43 PM, Anatole Tresch <atsti...@gmail.com> wrote:
>>
>> Hi all
>>
>> in the current branch we deprecated *ConfigOperator, ConfigQuery* in favour
>> of *UnaryOperator<Configuration> and Function<Configuration,T>. *This would
>> allow us to reduce the
>> API footprint in the midterm, but introduces API incompatibilities.
>>
>> Since both interfaces are functional already, I could also *revert this
>> change and stay with the interfaces above and therefore not introduce any
>> incompatibilities on API side* (only on SPI side we have some).
>>
>> WDYT? Agree reverting this API change, including adaptation on the
>> extensions, mostly tamaya-functions ?
>>
>> J Anatole
>>
>>
>> --
>> *Anatole Tresch*
>> PPMC Member Apache Tamaya
>> JCP Star Spec Lead
>> *Switzerland, Europe Zurich, GMT+1*
>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
>> *Twitter: @atsticks, @tamayaconf*
>
