Nir,
I've created a new branch which contains all the changes which we've
discussed so far. It contains JUnit 4 tests (in backported form), and a
reduced API.
However, the changes made in the sandbox did not fully compile due to
package restrictions, and I had to make a bit more API
I made the title more specific :)
--John
On 05/10/2021 17:58, Nir Lisker wrote:
Looks good. I assume we will add more bindings in the future like
conditionOn or anything else that I would put under "extras", so maybe
the title could be more specific since there will be more fluent
bindings in
Looks good. I assume we will add more bindings in the future like
conditionOn or anything else that I would put under "extras", so maybe the
title could be more specific since there will be more fluent bindings in
the future?
On Tue, Oct 5, 2021 at 1:34 PM John Hendrikx wrote:
> I've created
I've created https://bugs.openjdk.java.net/browse/JDK-8274771
Please have a look.
--John
On 04/10/2021 17:51, Nir Lisker wrote:
I think that a PR can be created. The only point we need to decide is about
the subscription models we talked about above. ReactFX uses something
different for each,
On 04/10/2021 20:37, Michael Strauß wrote:
A little bit of bikeshedding here: I think this feature should be
thought of as a type-safe version of `Bindings.select`, which should
also be reflected in the terminology used (i.e. not map/flatMap). The
terminology, combined with the frequent
On 04/10/2021 17:51, Nir Lisker wrote:
I think that a PR can be created. The only point we need to decide is
about the subscription models we talked about above. ReactFX uses
something different for each, you use the same. That can determine if we
need different classes for each binding type.
A little bit of bikeshedding here: I think this feature should be
thought of as a type-safe version of `Bindings.select`, which should
also be reflected in the terminology used (i.e. not map/flatMap). The
terminology, combined with the frequent comparisons to reactive
libraries might make it seem
I think that a PR can be created. The only point we need to decide is about
the subscription models we talked about above. ReactFX uses something
different for each, you use the same. That can determine if we need
different classes for each binding type.
I can create the JBS issue for this one
I’m no expert here so take it with a grain of salt but…
I was proposing moving this sorts of ObservableValue type interfaces and
implementations out of jfx (and React) context and into JDK context. Then
these sorts of observable type properties/ bindings can be used outside of
just UI contexts.
I'm not sure what you're proposing. Move what, to where, and for what use?
On Tue, Sep 21, 2021 at 8:02 PM Eric Bresie wrote:
> I’m very much an Observer here ;-) but
>
> Given the comparisons with FX and React implementations, is there value in
> moving some of this out of here and into the
I’m very much an Observer here ;-) but
Given the comparisons with FX and React implementations, is there value in
moving some of this out of here and into the JDK proper context making it
potentially usable outside of fx or react circles?
I’m reminded of old JDK workings when someone might be
>
> The OrElseBinding is incorrect
>
Yes, that was a typo with the order of the arguments in the ternary
statement.
I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
> think the tests would become pretty unreadable and less useful /
> thourough otherwise).
>
> What are the
I need to get you the tests I wrote, unfortunately, they're JUnit 5,
please see the tests here:
https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
The OrElseBinding is incorrect, the compute value should read:
protected T computeValue() {
I've played around with the implementation and pushed a modified
prototype to the sandbox [1]. I ended up with something similar to ReactFX:
the orElse and orElseGet methods have their own binding classes that
extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The
reason being that
On 15/09/2021 02:28, Nir Lisker wrote:
Sorry, I'm not quite sure what you mean by this. Could you elaborate?
The methods orElse and orElseGet are present in the PoC, and I think
they're highly useful to have to deal with nulls.
The methods that you call orElse and orElseGet
>
> Sorry, I'm not quite sure what you mean by this. Could you elaborate?
> The methods orElse and orElseGet are present in the PoC, and I think
> they're highly useful to have to deal with nulls.
The methods that you call orElse and orElseGet return an
ObservableValue. The Optional methods with
On 14/09/2021 03:14, Nir Lisker wrote:
Sounds good.
Some points I have (maybe some are premature):
1. I still think that adding the Optional methods for orElse and orElseGet
could be useful. Unless I can be convinced otherwise, I suggest that we be
careful with the naming of current methods
Sounds good.
Some points I have (maybe some are premature):
1. I still think that adding the Optional methods for orElse and orElseGet
could be useful. Unless I can be convinced otherwise, I suggest that we be
careful with the naming of current methods that return a binding.
2. I see that in
On 12/09/2021 02:05, Nir Lisker wrote:
I've gotten back to look at this.
For now I'm dealing only with the nullableMapping method in Bindings so
we can limit the amount of new classes to LazyObjectBinding
(FlatMapBinding and ConditionalBinding can come later). This method is
used by map,
I've gotten back to look at this.
For now I'm dealing only with the nullableMapping method in Bindings so we
can limit the amount of new classes to LazyObjectBinding (FlatMapBinding
and ConditionalBinding can come later). This method is used by map, orElse
and orElseGet in ObservableValue. Of
On 07/04/2021 03:41, Nir Lisker wrote:
In the PoC I made I specifically also disallowed 'null' as an input
I like the way ReactFX does it where the property is empty. I think that
this is also what you mean by disallowing `null` (in other contexts,
"disallowing null" would mean throwing an
>
> In the PoC I made I specifically also disallowed 'null' as an input
>
I like the way ReactFX does it where the property is empty. I think that
this is also what you mean by disallowing `null` (in other contexts,
"disallowing null" would mean throwing an exception).
Not entirely sure what you
On 02/04/2021 08:47, Nir Lisker wrote:
Hi John,
I've had my eyes set on ReactFX enhancements for a while too, especially as
a replacement for the unsafe "select" mechanism. One of the things that
kept me from going forward with this is seeing what Valhalla will bring.
Generic specialization
Hi John,
I've had my eyes set on ReactFX enhancements for a while too, especially as
a replacement for the unsafe "select" mechanism. One of the things that
kept me from going forward with this is seeing what Valhalla will bring.
Generic specialization might save a lot of duplication work on
I just wanted to draw some attention to a recent proof of concept I made
in this pull request: https://github.com/openjdk/jfx/pull/434
It is based on the work I did in
https://github.com/hjohn/hs.jfx.eventstream which is in part based on
work done in ReactFX by Tomas Mikula. The PR itself
25 matches
Mail list logo
