[jira] [Commented] (PIVOT-1047) Make sure that as many listener interfaces as possible can be used with lambdas

["Roger Lee Whitcomb (Jira)" <ji...@apache.org>]

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

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

Did the same thing for Sheet*Listener:
Sending        wtk/src/org/apache/pivot/wtk/SheetCloseListener.java
Sending        wtk/src/org/apache/pivot/wtk/SheetStateListener.java
Transmitting file data ..done
Committing transaction...
Committed revision 1877272.


> 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)