Huh? What does the EDT have to do with property binding?
On Sep 18, 11:21 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> The best part of this approach is that streams can be composed and filtered,
> so you could take window.height, and subtract splitbar.position to yield a
> new stream
> (operator overloading and closures help here)
> The result, also a stream, can then be assigned to the height of a panel in
> a window layout.
Sounds like needless complication to me. If properties with binding
had existed and I needed this, you can bind with a filter, and you can
choose whether it should be one-way (changing the window size changes
the panel) or two-way (changing the panel's height also scales up the
entire window). Yes, closure support would be handy to make the filter
API nicer, but I don't see how treating the property as a blocking
iterator helps. In fact, it hurts, a lot. It means you need a
bajillion threads. This isn't a big deal these days, you can have
thousands on a single system, but it does gulp down quite a bit of
memory to maintain all those stacks. It would look something like
this:
window.height.addOnChange(#(h) {
panel.height = h / 3;
}
looks elegant, easy to read, easy to maintain, and flexible to me!
With your stream example, it would have to look like this (I'm sure
I'm screwing this up, it can't be this obtuse!):
new Thread(#() {
for (int h : window.height.stream()) {
panel.height.push(h / 3);
}
}).start();
It also doesn't appear to solve the endless loop issue that can be a
bit complicated to avoid when specifying the properties system: If you
bind A to B and B to C, how do we ensure that changing for example A
doesn't cause an endless cascade of property updates, each continuing
the endless loop by issues new onChange calls? The usual solution is
to not propagate a new change event when a new value equals the old
value, and that works. An addition can be that if A is changed in the
middle of A itself propagating an earlier change, an exception is
thrown (because this is not going to end well).
Using an iterator is not going to make any of that any easier.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
