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
On Wed, May 11, 2016 at 11:35 PM David Orme
<[email protected] <mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[email protected]>, Web:
http://www.vogella.com
_______________________________________________
e4-dev mailing list
[email protected] <mailto:[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
--
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: [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
