pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger Whitcomb (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
Date Thu, 01 Feb 2018 20:51:00 GMT

     [ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Roger Whitcomb closed PIVOT-1011.
    Resolution: Fixed

I am satisfied, looking through the code, that this change is complete.

> Move ListenerList implementations of interfaces into the interface itself
> -------------------------------------------------------------------------
>                 Key: PIVOT-1011
>                 URL: https://issues.apache.org/jira/browse/PIVOT-1011
>             Project: Pivot
>          Issue Type: Improvement
>          Components: core-collections, core-util, web, wtk, wtk-terra
>         Environment: All
>            Reporter: Roger Whitcomb
>            Assignee: Roger Whitcomb
>            Priority: Minor
>         Attachments: 1011.diffs
> A universal paradigm in Pivot is to have a "listener" interface for a class or data structure
that is used to notify listeners of changes in the class/data.  There is then an "Adapter"
static class in the interface file that implements the interface with default implementations.
 Then there is a very separate enclosed static class that implements the "ListenerList" interface
of that listener interface.  And usually (or always) this "listener list" class is defined/used
only in the class that needs to notify the listeners.  However, this class must be very parallel
to not only the interface itself, but also the "Adapter" class, and yet it is in a different
> So, it seems somewhat reasonable to move all these "listener list" classes into the interfaces
themselves, so all three related things are located in the same file.  A preliminary POC of
this concept was done with "Query.java", and "QueryListener.java" and it looks good.
> This doesn't seem to require changes to client code, because the accessor methods only
refer to "ListenerList<....>" and not to the listener list class itself (in order to
be more general, of course), but which helps us to hide the implementing class away inside
the interface.
> I will attach the diff of the POC, to hopefully make this more clear.  It may seem a
somewhat nebulous concept, but the idea is to keep "like things" together for clarity.

This message was sent by Atlassian JIRA

View raw message