Am 24.03.2014 um 15:36 schrieb Martin Sladecek <martin.slade...@oracle.com>:
> On 24.3.2014 15:24, Mario Ivankovits wrote: >> But, after this discussion I do not see why one ever used .equals() at all. >> >> Look, it does not fit my needs, I do not see any use-case where one would >> add an removeListener with asymmetric .equals() and thus it is better you >> use == I think. >> This clarifies that EXACTLY the added listener instance is required to >> remove any listener AND it gives no room to discussions like we had because >> the indention is perfectly clear - even to those reading JavaFX core code >> and bug fixing things in JavaFX. >> For me this would be fine and understandable - I will go the >> decorator-cache-map so I will be fine always. > > One example might be in bidirectional binding. There's a special listener > that takes the 2 properties that are bound together and it's equals returns > true if the other listener is of the same class and it's two properties (no > matter in what order) are identical. This way, you can just write > Bindings.unbindBidirectional() and the internal implementation does not need > to remember the listener instance anywhere. The equals() is symmetric in this > case, but == would not work here. > > -Martin Ah - Thanks for this lesson! :-) OMG … just looked up the code. The implementation of BidirectionalBinding uses weak references and it might happen that you ExpressionHelperBase.trim() them out of the listener list if either side of the bound property got garbage collected. This means, if I decorated them, they will stay in my map because there is add/removeListener asymmetry. (just to use the word symmetry again ;-) ) So, it is even more complicated to decorate that stuff. How much I’d love to see a DecoratedListener interface like you have for WeakListener … but yay … :-( Thanks for listening anyway! :-) Regards, Mario
