ok, thats perfect for me. Just wanted to see what you guys think. If you
see further simplifications let us know ;)
J Anatole
Am Mo., 14. Jan. 2019, 16:41 hat William Lieurance <
william.lieura...@namikoda.com> geschrieben:
> 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*
> >
>
>
