[8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method

[Tomas Mikula]

On Wed, Jan 22, 2014 at 11:27 AM, Tom Schindl
<tom.schindl at bestsolution.at>wrote:

> On 22.01.14 11:07, Martin Sladecek 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.
>
> Well this would destroy the order! I expect listeners to be called in
> the correct order not? Why doing a remove and not simply check if the
> listener has already been added?


I, too, rely on the implementation detail that listeners are called in the
order of registration. My code doesn't break as long as the internal JavaFX
implementation keeps using Lists. I will just not use ensureListener()
where the order matters.

Tomas