Well it is just an fictive example. But for instance, there could be game rules 
that required us to listen to the energyPoints of all spaceships that had ever 
been part of the group. Perhaps the group would dissolve if more than 10 
spaceships that had ever been part of the group where shot down.

There could be many reasons why, and I certainly don’t think JavaFX should keep 
us from avoiding duplicate listeners.

Yours

Randahl



On 22 Jan 2014, at 14:29, Tomas Mikula <tomas.mik...@gmail.com> wrote:

> Thanks for an example. I imagined something analogous to your example, but 
> the part I'm curious about is this
> 
> "We still wanted to listen to a property of the spaceship, but now it was no 
> longer part of the group."
> 
> Why would you want to keep listening to that spaceship after removal from the 
> group?
> 
> Regards,
> Tomas
> 
> 
> On Wed, Jan 22, 2014 at 2:11 PM, Randahl Fink Isaksen <rand...@rockit.dk> 
> wrote:
> Hi Tomas
> 
> About the example you request: Say you and I implemented a computer game with 
> spaceships on screen, and lets imagine that these spaceships attacked in 
> groups. Everytime a spaceship was added to a group, we wanted to listen to a 
> property of that spaceship from that point in time and until eternity. Then, 
> imagine we took out a spaceship from the group. We still wanted to listen to 
> a property of the spaceship, but now it was no longer part of the group. 
> Then, imagine we added the same spaceship to the same group once more. At 
> this point, we don’t know if we have added the spaceship before, so when we 
> write
> 
> spaceship.someProperty.addListener(ourListener);
> 
> we suddenly have ourListener added twice to the property.
> 
> I know we can write removeListener(ourListener) followed by 
> addListener(ourListener), and while that would work, I would much rather have 
> the listener list ensure that there are no duplicates, since I believe that 
> it is always a bug to register the same listener twice.
> 
> Yours
> 
> Randahl
> 
> 
> 
> On 22 Jan 2014, at 13:34, Tomas Mikula <tomas.mik...@gmail.com> wrote:
> 
>> 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
>> 
>> 
> 
> 

Reply via email to