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 <[email protected]> wrote: > Huh? What does the EDT have to do with property binding? > > On Sep 18, 11:21 pm, Kevin Wright <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail / gtalk / msn : [email protected] 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
