[
https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282722#comment-16282722
]
Roger Whitcomb commented on PIVOT-1011:
---------------------------------------
Found a fundamental flaw in the naming conventions: "List" is not a good name,
because anything that extends one of these .Adapter classes will also have the
static "List" class defined, which will give a compile error if "List" (as in
collections.List) is used inside the subclass.
So, I suggest renaming these "xxxListener.List" static classes to
"xxxListener.Listeners" class. There should be no conflict with "Listeners"
because there are no Java or Pivot classes with that name. A bit uglier, but
since these are just used internally, there shouldn't be much user impact, if
any.
> 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
> place.
> 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
(v6.4.14#64029)
