Well, the topic of this thread was "Ability to decorate ChangeListener“
So, any solution, provided by JavaFX core, would have been fine … I still think
this would be nice, proposing the if flip was a fault for this discussion ...
Unhappily :-(
Am 24.03.2014 um 16:19 schrieb Stephen F Northover
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 2014-03-
On Mon, Mar 24, 2014 at 3:24 PM, Mario Ivankovits 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
> an remov
Am 24.03.2014 um 15:36 schrieb Martin Sladecek :
> 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
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 clari
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
an removeListener with asymmetric .equals() and thus it is better you use == I
Hi Mario,
On Mon, Mar 24, 2014 at 8:46 AM, Mario Ivankovits wrote:
> 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.
I'm curious why you need to decorate the listeners in the first place.
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 th
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
On Sat, Mar 22, 2014 at 4:11 PM, Mario Ivankovits 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
terms: if 1 decora
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 a
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 pr
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
mailto:kevin.rushfo...@oracle.com>>:
What if changeListeners[index] is null? Maybe this is already illegal
Anyway, l
What if changeListeners[index] is null? Maybe this is already illegal
Anyway, let's see what Martin has to say. In the mean time you file a
JIRA enhancement request (issuetype=Tweak) if you like.
-- Kevin
Mario Ivankovits wrote:
The only thing which I ask for is to flip this „if" in the
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 (changeLis
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 further.
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 sy
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener listener) {
super.removeListener(decorated(listener));
}
And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).
Regards,
Tomas
On Sat
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 MyObservableValue implements Obse
19 matches
Mail list logo
