You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Andres Almiray (JIRA)" <ji...@apache.org> on 2014/12/10 12:48:12 UTC

[jira] [Commented] (TAMAYA-22) Do we really need ConfigOperator?

    [ https://issues.apache.org/jira/browse/TAMAYA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240982#comment-14240982 ] 

Andres Almiray commented on TAMAYA-22:
--------------------------------------

True, though I think it's a matter of preference (pardon the pun) or being semantically explicit. Do you want to work with an API that makes extensive use of JDK's base functions (with the proper generics) or a domain specific abstraction (such as {{ConfigOperator}} that happens to behave like {{UnaryOperator<Configuration>}}.

Another thing to keep in mind is that we might switch to JDK7 in the future if we discover that JDK8 doesn't add too much value, thus all usages of functors and operators would have to be translated into Tamaya specific interfaces.

> Do we really need ConfigOperator?
> ---------------------------------
>
>                 Key: TAMAYA-22
>                 URL: https://issues.apache.org/jira/browse/TAMAYA-22
>             Project: Tamaya
>          Issue Type: Bug
>          Components: API
>    Affects Versions: 0.1-incubating
>            Reporter: Werner Keil
>              Labels: api-change, design
>
> As of now using Lambdas (since {{@FunctionalInterface}} and similar types are heavily used) limit the minimal Java version for Tamaya to SE 8. 
> Unless this was to change, the {{ConfigOperator}} interface seems rather redundant. Using {{UnaryOperator<Configuration>}} instead would simplify the API and make it even more Lambda-friendly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)