[
https://issues.apache.org/jira/browse/PIVOT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070212#comment-17070212
]
Roger Lee Whitcomb commented on PIVOT-1047:
-------------------------------------------
Move the default implementation of "dialogClosed" into DialogStateListener for
those callers that implement it, but had no
default (relying on the default in DialogCloseListener).
Sending wtk/src/org/apache/pivot/wtk/DialogStateListener.java
Transmitting file data .done
Committing transaction...
Committed revision 1875834.
> 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)
