I agree that streams are a good way to capture user inputs. Makes sense. I think something more akin to sideeffect + computedvalue is better for outputs... so having facilities in databinding that can support both models makes sense. You'd get the benefits of both worlds.
But -- just thinking -- I wonder if you even need any observables for the user input case? Maybe you could just go directly from SWT events to streams without any intermediate observables? - Stefan On Wed, May 11, 2016 at 11:35 PM David Orme <[email protected]> wrote: > Hi Stefan, > > Here's a use-case to motivate Lazy Iterables (or streams): > > Suppose you want to implement rubber-banding on a Canvas. Right now you > can't do that elegantly with data binding. > > To implement rubber-banding, one must capture MouseDown, MouseMove, and > MouseUp. Right now, one might create a state machine object where the > object's state is manipulated by each individual event. This gets clumsy > and hard to debug fast. > > I've thought it would be nice to, on mouse-down, create an Iterable stream > tracking MouseMove and MouseUp. MouseUp would be registered as the event > terminating the Iterable stream. One could then simply call a function > with the coordinates of the MouseDown, along with the Iterable. The > function can iterate over the events in the stream, process the > rubber-banding operations, and return an "Object created" (or maybe > "Objects selected") message when the rubber band operation completes. > > The advantage is that all stateful operations stay inside a single > function that just loops over an Iterable. You get functional purity in a > highly stateful environment. > > One could apply the same logic to the Streams API, with the advantage that > the looping is also abstracted away (the whole rubber-band operation > becomes a reduce over the event stream). > > No more time to write tonight. > > For calculations, I agree that ComputedValue is nice, and I really like > the ideas in the Cells Manifesto > <http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html>. > > > Regards, > > Dave > > On Wed, May 11, 2016 at 9:31 AM Stefan Xenos <[email protected]> wrote: > >> I'm definitely a fan of making Obervables interoperable with as many >> different programming models as possible... but I wouldn't personally >> choose streams or iterables as the mechanism for combining observables - at >> least not in my own code. >> >> That would create a programming model very much like rxjava -- which >> works fine, but it's quite hard to debug and it requires memorizing a lot >> of operators. My own preference is to use ComputedValue as the mechanism >> for combining observables. >> >> For example: >> >> IObservableValue<String> fullName = ComputedValue::create(() -> {return >> firstName.getValue() + " " + lastName.getValue();}) >> >> It's definitely less general than a stream-based approach, but I find the >> code much more readable in the (very common) cases where it works. That >> said: we should definitely support utilities that make it easy to >> interoperate between observables and steams, etc. >> >> I'm not familiar with infinite iterables. How would you actually combine >> them? >> >> On Wed, May 11, 2016 at 9:42 AM David Orme <[email protected]> >> wrote: >> >>> I'll have to look at the code to appreciate the implications of this. >>> >>> House about these thoughts: >>> >>> - Create adapters for IObservables to Java 8's streams >>> - Adapt IObservables to lazy infinite Iterables using a Java >>> continuations library and provide ways to compose groups of Iterables into >>> combined streams. Then reactive code can be expressed as loops over >>> Iterables and state can stay with the code that operates on it. >>> >>> See also: the Cells Manifesto. Sorry, I'm typing on my phone so don't >>> have the link handy. >>> >>> Dave >>> >>> >>> On Wed, May 11, 2016, 8:09 AM Stefan Xenos <[email protected]> wrote: >>> >>>> The Bind class described there would provide a fluent form way to >>>> create bindings, but IMO an even better approach would be to use >>>> ISideEffect as a replacement for bindings and data binding context. It can >>>> do everything bindings could, but it's much more flexible. Simon has >>>> already written a number of examples. >>>> >>>> - Stefan >>>> >>>> On Wed, May 11, 2016 at 9:01 AM David Orme < >>>> [email protected]> wrote: >>>> >>>>> I have interest in picking this up again, but have a few other things >>>>> on my plate to attend to first. (My blog has been idle for awhile but if >>>>> you watch Planet Eclipse, hopefully sooner than later you'll see that >>>>> change.) On the other hand, my current employer gives my cycles to work >>>>> on >>>>> this sort of thing. >>>>> >>>>> What were you wanting to see happen? I have ideas too... >>>>> >>>>> (I was one of data binding's original architects along with Boris >>>>> Bokowski.) >>>>> >>>>> Dave >>>>> >>>>> On Wed, May 11, 2016, 5:45 AM Lars Vogel <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Erdal, >>>>>> >>>>>> AFAIK nobody is currently working on this branch. AFAIK Stefan Xenos >>>>>> (cc) cherry-picked and reworked some of the generics works from this >>>>>> repo but any further enhancement of databinding did occur in the main >>>>>> platform UI repository. >>>>>> >>>>>> Best regards, Lars >>>>>> >>>>>> On Fri, May 6, 2016 at 5:58 PM, Erdal Karaca < >>>>>> [email protected]> wrote: >>>>>> > Hi all, >>>>>> > I checked out the git repo of the "New Binding API", but it seems >>>>>> there is >>>>>> > not much activity. >>>>>> > >>>>>> > The DataBindingContext class provided a possibility for aggregating >>>>>> status >>>>>> > of its bindings. With the new proposal this does not seem to be >>>>>> possible >>>>>> > anymore. >>>>>> > >>>>>> > What are the plans for the "New Binding API"? >>>>>> > >>>>>> > https://wiki.eclipse.org/JFace_Data_Binding/The_New_Binding_API >>>>>> > >>>>>> > Best regards, >>>>>> > Erdal >>>>>> > >>>>>> > _______________________________________________ >>>>>> > e4-dev mailing list >>>>>> > [email protected] >>>>>> > To change your delivery options, retrieve your password, or >>>>>> unsubscribe from >>>>>> > this list, visit >>>>>> > https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Eclipse Platform UI and e4 project co-lead >>>>>> CEO vogella GmbH >>>>>> >>>>>> Haindaalwisch 17a, 22395 Hamburg >>>>>> Amtsgericht Hamburg: HRB 127058 >>>>>> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel >>>>>> USt-IdNr.: DE284122352 >>>>>> Fax (040) 5247 6322, Email: [email protected], Web: >>>>>> http://www.vogella.com >>>>>> _______________________________________________ >>>>>> e4-dev mailing list >>>>>> [email protected] >>>>>> To change your delivery options, retrieve your password, or >>>>>> unsubscribe from this list, visit >>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>> >>>>>
_______________________________________________ e4-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
