Hi Randahl, I'm curious about an example where you would take advantage of the behavior where multiple addListener(listener) calls add the listener just once.
Anyway, here [1] are helper classes InvalidationSubscriber and ChangeSubscriber that allow you to do that: InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, listener); subscriber.subscribe(); // registers the listener subscriber.subscribe(); // no-op Cheers, Tomas [1] https://gist.github.com/TomasMikula/8557825 On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen <rand...@rockit.dk>wrote: > Hi Martin > > While I agree your proposed solution would work, I still don’t understand > why JavaFX should keep on supporting duplicates in listener collections. > Can anyone come up with just 1 example of an application that might be > depending on having two listeners on the same Observable? E.g. this kind of > code: > > myObservable.addListener(myChangeListener); //add it > myObservable.addListener(myChangeListener); //add it again > > In what kind of situation would this sort of code make any sense? > > If we all feel confident that the presence of duplicates listeners is > always an error, I warmly recommend changing the API to be duplicate free. > > Yours > > Randahl > > > > > On 22 Jan 2014, at 11:07, Martin Sladecek <martin.slade...@oracle.com> > wrote: > > > Hi all, > > I would like to start discussion about an addition to API in Observable, > ObservableValue and all Observable collections. > > There were multiple requests for a way how to avoid duplicates in > listeners lists. The way RT-25613 solves this is that it introduces public > boolean hasListener(ListenerType listener) which would return true if the > provided listener is already registered. > > > > This has one significant drawback that all of Observable* are actually > interfaces. Means we can only add hasListener as a defender method. The > problem is with the default implementation. We cannot return anything > meaningful, so we have to throw an UnsupportedOperationException. The > problem is that this might blow up unexpectedly when some "older" > Observable implementation is used. Also, it might be easy to miss when > implementing the interface, since the IDE might not force you to implement > it. > > > > So as an alternative solution, I propose adding something like: > > > > ensureListener(ListenerType listener) > > > > which would make sure the listener is on the list and if a listener is > already present, the number of times listener is registered on the > Observable will NOT grow after this call. > > > > The default implementation (for Observable) would look like this: > > > > public default void ensureListener(InvalidationListener listener) { > > removeListener(listener); > > addListener(listener); > > } > > > > subclasses might do something more effective. The same would apply to > ObservableValue and ChangeListener and Observable[List|Set|Map] and > [List|Set|Map]ChangeListener. > > > > What do you think? > > > > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 > > > > -Martin > >
