pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger Lee Whitcomb (Jira)" <j...@apache.org>
Subject [jira] [Commented] (PIVOT-1047) Make sure that as many listener interfaces as possible can be used with lambdas
Date Fri, 30 Apr 2021 22:09:00 GMT

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

Roger Lee Whitcomb commented on PIVOT-1047:
-------------------------------------------

PIVOT-1047,PIVOT-1032: Make TextInputSelectionListener back into a FunctionalInterface by
removing default implementation; fix "checkstyle" problems.

Sending        wtk/src/org/apache/pivot/wtk/TextInputSelectionListener.java
Transmitting file data .done
Committing transaction...
Committed revision 1889346.


> Make sure that as many listener interfaces as possible can be used with lambdas
> -------------------------------------------------------------------------------
>
>                 Key: PIVOT-1047
>                 URL: https://issues.apache.org/jira/browse/PIVOT-1047
>             Project: Pivot
>          Issue Type: Improvement
>          Components: core, wtk, wtk-terra
>            Reporter: Roger Lee Whitcomb
>            Assignee: Roger Lee Whitcomb
>            Priority: Major
>             Fix For: 2.1.0
>
>
> Earlier we had (for Java 8 compatibility) made most/all interfaces implement default
methods so that the Adapter classes could be deprecated. But in working with these, it appears
that defaulting ALL the methods makes them unusable as lambdas.
> For instance, DialogCloseListener has just one interface method, perfect for a lambda,
except with default it isn't eligible. By simply making it pure abstract there are no negative
consequences, and makes it much more useful. By this I mean, with only one method, the only
reason to instantiate one would be to implement the one, so "default" doesn't really make
sense, while abstract/lambda is perfect.
> Investigate this for other interfaces, as some are more problematic, such as TextInputContentListener,
which has multiple "useful" methods, so the trick would be picking just one (the most commonly
implemented one?) to make abstract. Or ListButtonSelectionListener which has two roughly equally
useful methods, where we would typically use one or the other, but not both. So, making it
lambda-compatible doesn't really help much, in terms of usability.
> Others such as Validator are already abstract and need no change, except they could be
marked with the @FunctionalInterface annotation to make this clear.
> Careful investigation is needed, since it is possible that making one method abstract
means the Adapter class might not be suitable for Deprecation anymore either; not sure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message