Hi,
I'm not sure whether this fits to the discussion, but this talk at
EcliseCon NA might be interesting for you:
https://www.eclipsecon.org/na2016/session/rxjava-and-swt-out-events-frp
On this website there's also a link to the GitHub Project and the
Slides are also available.
- Simon
On 12.05.2016 05:59, Stefan Xenos
wrote:
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
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.
Regards,
Dave
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?
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
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.
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
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 <erdal.karaca.de@xxxxxxxxx>
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
> e4-dev@xxxxxxxxxxx
> 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: lars.vogel@xxxxxxxxxxx,
Web: http://www.vogella.com
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
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
e4-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/e4-dev
--
Trainer, Consultant and Developer
vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Tel (040) 78804360, Fax (032) 221739404, Email: simon.scholz@xxxxxxxxxxx, Web: http://www.vogella.com
|
