ent and I
> cannot imagine a later date being better than now to get this change in.
>
> Sent from a tiny keyboard
>
>
> From: Aaron Coburn
> Sent: Monday, January 14, 2019 9:36:04 AM
> To: dev@tamaya.incubator.apache.org
> Subject: Re
@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
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
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 and simultaneously
2. Deprecate
Hi all
in the current branch we deprecated *ConfigOperator, ConfigQuery* in favour
of *UnaryOperator and Function. *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
