Behind the scenes, this is a form of dataflow concurrency, delimited
continuations being the secret sauce that makes it all work.
(if you're familiar with continuations in Jetty 7, you'll have a broad idea
of the technique)
So, yes, threads are involved, but not in the way you imagine.
On 19 September 2010 06:38, Reinier Zwitserloot <reini...@gmail.com> wrote:
> 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<javaposse%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
Kevin Wright
mail / gtalk / msn : kev.lee.wri...@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
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.
