Mario,
thanks for your suggestion, but I think your specific case will not
justify the change. First of all, as it was already said, equals should
be symmetric. Knowing the implementation, you could rely on the fact
that either the equals is called on the provided listener or on the
listeners
Thanks for your answer!
One thing, I think, we can agree on, is that it is overly complex for an OO
language to decorate things like these listeners.
What about introducing another interface like ChangeListenerDecoration with a
special named „boolean decorates(ChangeListener)) method and call
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
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
On Mon, Mar 24, 2014 at 3:24 PM, Mario Ivankovits ma...@datenwort.at wrote:
Hi Tomas!
No worries, I’ll go the way on my own there then.
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
I'm pretty sure this discussion has solidified around not flipping the
equals() but this is a good example of something that we wouldn't
change. If you write code that relies on this, it will break in the
future when new code is added in FX that does not follow the pattern.
Steve
On
The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.
In case the observable value is visible only within your project, you
could do this:
interface Subscription {
void unsubscribe();
}
class MyObservableValueT implements
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener? super T listener) {
super.removeListener(decorated(listener));
}
And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).
Regards,
Hi Thomas!
Thanks for your input. Because I want to decorated listeners added by JavaFX
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult
a map where the decorated listeners and their undecorated one lives.
Regarding the
If you are talking about a change to the JavaFX API, we are not likely
to accept such a change if it breaks the contract of equals() or
hashcode(). In your own app it may not matter, but it is dangerous to
assume it won't matter to anyone. Martin owns the core libraries and can
comment
The only thing which I ask for is to flip this „if in the *ExpressionHelper
classes:
So, JavaFX does not break anything and it is up to the app developer to take
the risk or not.
if (listener.equals(changeListeners[index])) {
If we flip this to
if
Yep, null throws a NullPointerException in addListener by design (also in
removeListener) - the listener collection is safe.
Am 22.03.2014 um 15:50 schrieb Kevin Rushforth
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:
What if changeListeners[index] is null? Maybe this is
Hi Mario,
even if your proposal gets accepted, you would still depend on an
implementation detail of JavaFX, which is always good to avoid.
To sum up, my second proposal compared to your current solution:
(+) your equals() stays symmetric;
(+) no need for an extra Map of listeners.
My second
Probably you avoid the map, but it requires to decorate the listener again,
right?
If you think about the tons of observable values and add/removeListener
operations in an tree view when scrolling it might get costly and put pressure
on the GC.
Anyway, I will be more than happy to assist with
On Sat, Mar 22, 2014 at 4:11 PM, Mario Ivankovits ma...@datenwort.at wrote:
Probably you avoid the map, but it requires to decorate the listener again,
right?
Right. For a pair of addListener-removeListener calls, you have 2
decorations instead of 1. I usually think of the costs in asymptotic
Hi!
In one of my ObservableValue implementations I do have the need to decorate
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the
original listener to the decorated one to being able to handle the removal
process of a listener. Because
16 matches
Mail list logo
