Re: [announce] InhiBeans: mitigate redundant recalculations

2014-01-16 Thread Alexander Kouznetsov

There are two other options you may want to consider:

1) Use XXXBinding as following:

value.bind(new DoubleBinding() {
{ bind(widthProperty(), heightProperty()); }

@Override
protected Double computeValue() {
return widthProperty().get() * heightProperty().get();
}
}

this will perform the same invalidation mechanics for you as long as 
your value is not requested immediately after change. JavaFX is mostly 
lazy so if you, for example, bind it to some node's property it will be 
calculated only once.


2) Use AnimationTimer. Its body is always invoked once per pulse so you 
can do as much calculations you need once per pulse.


Best regards,
Alexander Kouznetsov
(408) 276-0387

On 15 дек 2013 23:30, John Hendrikx wrote:
Since you are only allowed to modify properties on the JavaFX thread 
(in most cases), I've been using Platform.runLater() to make sure I 
observe only complete changes.


Basically I register an InvalidationListener on the properties that 
are relevant, and when one gets triggered I set a boolean and trigger 
a Runnable that
will be run on the JavaFX thread later (and after the change 
completes).  The Runnable checks the relevant values and acts on them, 
then resets the boolean.


I use this mechanism for example when I'm observing Objects with many 
properties that need to be stored in a database.  To make sure I only 
store consistent objects, I only observe the values of the properties 
when my own little piece of observer code runs on the JavaFX thread.  
Since nothing can modify the properties except on the JavaFX thread, 
this is almost like a form of transactions, ensuring that every change 
has completed before observing the results.


--John

On 15/12/2013 18:39, Scott Palmer wrote:

Interesting idea.

There is a case I have been curious about and wonder what the best
practices are for it.  Suppose you have a case when you are changing
multiple different properties that will be used in a single calculation.
  You want to deal with a single change to all of them in one go.  E.g.
imagine you have an area property that is bound to both width and
height.  You want to write code like:

obj.setWidth(w);
obj.setHeight(h);

and have only ONE recalculation of the area property happen. 
Currently the

way bindings work the area will be calculated twice.  The intermediate
calculation is really not a value that you ever want to observe.

Are there helpers for this sort of situation?  Are there guidelines 
in the

JavaFX docs somewhere?

Regards,

Scott


On Sat, Dec 14, 2013 at 11:54 PM, Tomas 
Mikulatomas.mik...@gmail.comwrote:



Hello,

I just published a small extension of javafx bindings and properties
that can help you reduce redundant recalculations.

They provide two additional methods:

public void block();
public void release();

Call p.block() when you suspect your actions will lead to multiple
invalidations of p, and call p.release() when you are done and want to
deliver a single invalidation notification to p's observers.

https://github.com/TomasMikula/InhiBeans

Regards,
Tomas







Re: [announce] InhiBeans: mitigate redundant recalculations

2014-01-16 Thread Tomas Mikula
Hi Alexander,

On Thu, Jan 16, 2014 at 10:24 AM, Alexander Kouznetsov 
alexander.kouznet...@oracle.com wrote:

 There are two other options you may want to consider:

 1) Use XXXBinding as following:

 value.bind(new DoubleBinding() {
 { bind(widthProperty(), heightProperty()); }

 @Override
 protected Double computeValue() {
 return widthProperty().get() * heightProperty().get();
 }
 }

 this will perform the same invalidation mechanics for you as long as your
 value is not requested immediately after change. JavaFX is mostly lazy so
 if you, for example, bind it to some node's property it will be calculated
 only once.


in the past I tried binding Label.textProperty() to a value like this and
it was calculated twice.



 2) Use AnimationTimer. Its body is always invoked once per pulse so you
 can do as much calculations you need once per pulse.


As I mentioned before, this only works when the result is not observable by
the client code. Otherwise it might be reasonable to assert the following:

obj.setWidth(w);
obj.setHeight(h);
 assert obj.getArea() == w*h;

which is not true if area is only calculated on the next pulse.

Moreover, this approach doesn't scale. If you use the trick with next pulse
or runLater in several places in your code and then chain (bind) them, it
will take several pulses to propagate the change. Ironically, it then
doesn't even avoid multiple recalculations (e.g. analyze the case where
these parts depend on each other the way fibonacci numbers do: f[n+2] :=
f[n] + f[n+1]).

Regards,
Tomas



 Best regards,
 Alexander Kouznetsov
 (408) 276-0387


 On 15 дек 2013 23:30, John Hendrikx wrote:

 Since you are only allowed to modify properties on the JavaFX thread (in
 most cases), I've been using Platform.runLater() to make sure I observe
 only complete changes.

 Basically I register an InvalidationListener on the properties that are
 relevant, and when one gets triggered I set a boolean and trigger a
 Runnable that
 will be run on the JavaFX thread later (and after the change completes).
  The Runnable checks the relevant values and acts on them, then resets the
 boolean.

 I use this mechanism for example when I'm observing Objects with many
 properties that need to be stored in a database.  To make sure I only store
 consistent objects, I only observe the values of the properties when my own
 little piece of observer code runs on the JavaFX thread.  Since nothing can
 modify the properties except on the JavaFX thread, this is almost like a
 form of transactions, ensuring that every change has completed before
 observing the results.

 --John

 On 15/12/2013 18:39, Scott Palmer wrote:

 Interesting idea.

 There is a case I have been curious about and wonder what the best
 practices are for it.  Suppose you have a case when you are changing
 multiple different properties that will be used in a single calculation.
   You want to deal with a single change to all of them in one go.  E.g.
 imagine you have an area property that is bound to both width and
 height.  You want to write code like:

 obj.setWidth(w);
 obj.setHeight(h);

 and have only ONE recalculation of the area property happen. Currently
 the
 way bindings work the area will be calculated twice.  The intermediate
 calculation is really not a value that you ever want to observe.

 Are there helpers for this sort of situation?  Are there guidelines in
 the
 JavaFX docs somewhere?

 Regards,

 Scott


 On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikulatomas.mik...@gmail.com
 wrote:

  Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas






Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Tomas Mikula
On Mon, Dec 16, 2013 at 7:56 AM, Tom Eugelink t...@tbee.org wrote:

 I understand what you are trying to do. I was wondering if a more coarse
 grained approach would be preferable, so a central registration of whether
 or not to postpone change events.

 So:
 Central.postponeAllChangeEvents()
 Central.resumeAllChangeEvents()

 Or maybe both:
 p.postponeChangeEvents()
 p.resumeChangeEvents()


 I also foresee some unexpected behavior; suppose you have two properties
 bound bidirectionally. You set 1 on the first and 2 on the second, in the
 end both properties will be set to 2. Now you postpone change events and do
 the same, the end value depends on the order in which the components are
 resumed; if first component 2 is resumed its change event is fired before
 1 so in the end the properties will be set to 1. If there were a central
 toggle and postponed events were registered to that central toggle, than
 resuming events would play back the events in the same order they
 happened.

 Just some considerations.

 Tom

Hi Tom,

global postpone/resume defeats the original goal of avoiding multiple
change events. Consider

Central.postponeAllChangeEvents();
obj.setWidth(w);
obj.setHeight(h);
Central.resumeAllChangeEvents();

Now, if the changes are replayed, the width change causes one change
of the area property, and height change another one.

You are right about the problem with bidirectionally bound properties.
I don't know all the useful use cases for bidirectional bindings (I
never used them personally), but it might as well be the case that the
scenario you described never happens. InhiBeans are intended for
internal implementation of a component. Only the component itself
would call block()/release(). These methods aren't even available to
the client of the component without downcasting the properties.
Methods of the component can call block() internally, but should
release() before returning.

Regards,
Tomas



 On 2013-12-16 0:39, Scott Palmer wrote:

 Good stuff!   This is the sort of thing that might make a good
 contribution
 to extend the standard Bindings class.

 Scott


 On Sun, Dec 15, 2013 at 5:49 PM, Tomas Mikula
 tomas.mik...@gmail.comwrote:

 On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer swpal...@gmail.com wrote:

 Interesting idea.

 There is a case I have been curious about and wonder what the best

 practices

 are for it.  Suppose you have a case when you are changing multiple
 different properties that will be used in a single calculation.  You

 want to

 deal with a single change to all of them in one go.  E.g. imagine you

 have

 an area property that is bound to both width and height.  You want

 to

 write code like:

 obj.setWidth(w);
 obj.setHeight(h);

 and have only ONE recalculation of the area property happen.  Currently

 the

 way bindings work the area will be calculated twice.  The intermediate
 calculation is really not a value that you ever want to observe.

 Hi Scott,

 this is precisely the problem that I'm trying to address here. Now,
 the question is whether you have control over the implementation of
 obj.

 If yes, then it is the same case as the AND gate motivational
 example from InhiBeans page. You provide a method setSize(w, h) and
 use block()/release() to implement it in a way that causes only one
 change of the area property.

 If you cannot change the implementation of obj, what you can do is to
 bind an inhibeans.binding.DoubleBinding to the area value, call it
 relaxedArea, and listen to that one for all your purposes.
 Then you resize obj like this:

 relaxedArea.block();
 obj.setWidth();
 obj.setHeight();
 relaxedArea.release();

 Only one change of relaxedArea is emitted.

 Best,
 Tomas

 Are there helpers for this sort of situation?  Are there guidelines in

 the

 JavaFX docs somewhere?

 Regards,

 Scott


 On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.com
 wrote:

 Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas






Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Tomas Mikula
On Mon, Dec 16, 2013 at 12:17 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
 On Mon, Dec 16, 2013 at 7:56 AM, Tom Eugelink t...@tbee.org wrote:

 I understand what you are trying to do. I was wondering if a more coarse
 grained approach would be preferable, so a central registration of whether
 or not to postpone change events.

 So:
 Central.postponeAllChangeEvents()
 Central.resumeAllChangeEvents()

 Or maybe both:
 p.postponeChangeEvents()
 p.resumeChangeEvents()


 I also foresee some unexpected behavior; suppose you have two properties
 bound bidirectionally. You set 1 on the first and 2 on the second, in the
 end both properties will be set to 2. Now you postpone change events and do
 the same, the end value depends on the order in which the components are
 resumed; if first component 2 is resumed its change event is fired before
 1 so in the end the properties will be set to 1. If there were a central
 toggle and postponed events were registered to that central toggle, than
 resuming events would play back the events in the same order they
 happened.

 Just some considerations.

 Tom

 Hi Tom,

 global postpone/resume defeats the original goal of avoiding multiple
 change events. Consider

 Central.postponeAllChangeEvents();
 obj.setWidth(w);
 obj.setHeight(h);
 Central.resumeAllChangeEvents();

 Now, if the changes are replayed, the width change causes one change
 of the area property, and height change another one.

 You are right about the problem with bidirectionally bound properties.
 I don't know all the useful use cases for bidirectional bindings (I
 never used them personally), but it might as well be the case that the
 scenario you described never happens.

I should have added that I assume that you never use bidirectional
binding within one component, but only to bind properties of two
components.

 InhiBeans are intended for
 internal implementation of a component. Only the component itself
 would call block()/release(). These methods aren't even available to
 the client of the component without downcasting the properties.
 Methods of the component can call block() internally, but should
 release() before returning.

 Regards,
 Tomas



 On 2013-12-16 0:39, Scott Palmer wrote:

 Good stuff!   This is the sort of thing that might make a good
 contribution
 to extend the standard Bindings class.

 Scott


 On Sun, Dec 15, 2013 at 5:49 PM, Tomas Mikula
 tomas.mik...@gmail.comwrote:

 On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer swpal...@gmail.com wrote:

 Interesting idea.

 There is a case I have been curious about and wonder what the best

 practices

 are for it.  Suppose you have a case when you are changing multiple
 different properties that will be used in a single calculation.  You

 want to

 deal with a single change to all of them in one go.  E.g. imagine you

 have

 an area property that is bound to both width and height.  You want

 to

 write code like:

 obj.setWidth(w);
 obj.setHeight(h);

 and have only ONE recalculation of the area property happen.  Currently

 the

 way bindings work the area will be calculated twice.  The intermediate
 calculation is really not a value that you ever want to observe.

 Hi Scott,

 this is precisely the problem that I'm trying to address here. Now,
 the question is whether you have control over the implementation of
 obj.

 If yes, then it is the same case as the AND gate motivational
 example from InhiBeans page. You provide a method setSize(w, h) and
 use block()/release() to implement it in a way that causes only one
 change of the area property.

 If you cannot change the implementation of obj, what you can do is to
 bind an inhibeans.binding.DoubleBinding to the area value, call it
 relaxedArea, and listen to that one for all your purposes.
 Then you resize obj like this:

 relaxedArea.block();
 obj.setWidth();
 obj.setHeight();
 relaxedArea.release();

 Only one change of relaxedArea is emitted.

 Best,
 Tomas

 Are there helpers for this sort of situation?  Are there guidelines in

 the

 JavaFX docs somewhere?

 Regards,

 Scott


 On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.com
 wrote:

 Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas






Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Tomas Mikula
On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called and that
 naturally lead to thinking of try-with-resources, where the resource in
 this case is a binding of some sort (or a wrapper around a binding) that is
 invalidated on close() if needed.

 That is an interesting idea. I didn't intend blockWhile() to be safe
 with respect to exceptions, but merely

 void blockWhile(Runnable r) {
 block();
 r.run();
 release();
 }

 Enhancement you are suggesting could be fleshed out as block()
 returning an AutoCloseable and the usage would be

 try(AutoCloseable a = relaxedArea.block()) {
 obj.setWidth(w);
 obj.setHeight(h);
 }

OK, done. I implemented both:
1. added the blockWhile() method;
2. made bindings AutoCloseable, and block() returns `this`.

Tomas


Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Richard Bair
Have you looked at https://github.com/Netflix/RxJava by chance? I've been dying 
to see somebody do an RxJava in JavaFX ever since devoxx and it looks like you 
may have inadvertently started down that path :-). 

Richard

On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:

 On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called and that
 naturally lead to thinking of try-with-resources, where the resource in
 this case is a binding of some sort (or a wrapper around a binding) that is
 invalidated on close() if needed.
 
 That is an interesting idea. I didn't intend blockWhile() to be safe
 with respect to exceptions, but merely
 
 void blockWhile(Runnable r) {
block();
r.run();
release();
 }
 
 Enhancement you are suggesting could be fleshed out as block()
 returning an AutoCloseable and the usage would be
 
 try(AutoCloseable a = relaxedArea.block()) {
obj.setWidth(w);
obj.setHeight(h);
 }
 
 OK, done. I implemented both:
 1. added the blockWhile() method;
 2. made bindings AutoCloseable, and block() returns `this`.
 
 Tomas



Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Tomas Mikula
As a matter of fact, I have. Only to the extent of the Principles of
Reactive Programming [1] course that is currently in progress on
Coursera. From what I have seen so far, it's all about asynchronous
composition (with emphasis on both asynchronous and composition).
I didn't see it addressing this specific problem of multiple redundant
updates, but I might be wrong. The truth is, this problem doesn't even
exist if you don't have any eager observers (i.e. when you don't ever
attach any ChangeListeners, and InvalidationListeners only propagate
invalidation and never require the value to be recomputed). The
problem is, although you can design your component without any eager
evaluation (JavaFX bindings are already composed this way), you then
bind a Label.textProperty() to the end of a binding chain and it all
becomes eager.

Regards,
Tomas

[1] https://www.coursera.org/course/reactive

On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair richard.b...@oracle.com wrote:
 Have you looked at https://github.com/Netflix/RxJava by chance? I've been 
 dying to see somebody do an RxJava in JavaFX ever since devoxx and it looks 
 like you may have inadvertently started down that path :-).

 Richard

 On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:

 On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called and that
 naturally lead to thinking of try-with-resources, where the resource in
 this case is a binding of some sort (or a wrapper around a binding) that is
 invalidated on close() if needed.

 That is an interesting idea. I didn't intend blockWhile() to be safe
 with respect to exceptions, but merely

 void blockWhile(Runnable r) {
block();
r.run();
release();
 }

 Enhancement you are suggesting could be fleshed out as block()
 returning an AutoCloseable and the usage would be

 try(AutoCloseable a = relaxedArea.block()) {
obj.setWidth(w);
obj.setHeight(h);
 }

 OK, done. I implemented both:
 1. added the blockWhile() method;
 2. made bindings AutoCloseable, and block() returns `this`.

 Tomas



RE: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread John Smith
Perhaps reactive programming is different from the problem Tomas is solving, 
but I think a research project which combined some of the principles of 
functional reactive programming 
(http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf) with JavaFX 
properties using Java 8 lambdas and streams would be quite interesting and 
perhaps very useful.

John

-Original Message-
From: openjfx-dev-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tomas Mikula
Sent: Monday, December 16, 2013 9:19 AM
To: Richard Bair
Cc: openjfx-dev@openjdk.java.net
Subject: Re: [announce] InhiBeans: mitigate redundant recalculations

As a matter of fact, I have. Only to the extent of the Principles of Reactive 
Programming [1] course that is currently in progress on Coursera. From what I 
have seen so far, it's all about asynchronous composition (with emphasis on 
both asynchronous and composition).
I didn't see it addressing this specific problem of multiple redundant updates, 
but I might be wrong. The truth is, this problem doesn't even exist if you 
don't have any eager observers (i.e. when you don't ever attach any 
ChangeListeners, and InvalidationListeners only propagate invalidation and 
never require the value to be recomputed). The problem is, although you can 
design your component without any eager evaluation (JavaFX bindings are already 
composed this way), you then bind a Label.textProperty() to the end of a 
binding chain and it all becomes eager.

Regards,
Tomas

[1] https://www.coursera.org/course/reactive

On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair richard.b...@oracle.com wrote:
 Have you looked at https://github.com/Netflix/RxJava by chance? I've been 
 dying to see somebody do an RxJava in JavaFX ever since devoxx and it looks 
 like you may have inadvertently started down that path :-).

 Richard

 On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:

 On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called 
 and that naturally lead to thinking of try-with-resources, where 
 the resource in this case is a binding of some sort (or a wrapper 
 around a binding) that is invalidated on close() if needed.

 That is an interesting idea. I didn't intend blockWhile() to be safe 
 with respect to exceptions, but merely

 void blockWhile(Runnable r) {
block();
r.run();
release();
 }

 Enhancement you are suggesting could be fleshed out as block() 
 returning an AutoCloseable and the usage would be

 try(AutoCloseable a = relaxedArea.block()) {
obj.setWidth(w);
obj.setHeight(h);
 }

 OK, done. I implemented both:
 1. added the blockWhile() method;
 2. made bindings AutoCloseable, and block() returns `this`.

 Tomas



Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Richard Bair
I agree, that's more of what I was thinking. 

On Dec 16, 2013, at 10:31 AM, John Smith john_sm...@symantec.com wrote:

 Perhaps reactive programming is different from the problem Tomas is solving, 
 but I think a research project which combined some of the principles of 
 functional reactive programming 
 (http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf) with 
 JavaFX properties using Java 8 lambdas and streams would be quite interesting 
 and perhaps very useful.
 
 John
 
 -Original Message-
 From: openjfx-dev-boun...@openjdk.java.net 
 [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tomas Mikula
 Sent: Monday, December 16, 2013 9:19 AM
 To: Richard Bair
 Cc: openjfx-dev@openjdk.java.net
 Subject: Re: [announce] InhiBeans: mitigate redundant recalculations
 
 As a matter of fact, I have. Only to the extent of the Principles of 
 Reactive Programming [1] course that is currently in progress on Coursera. 
 From what I have seen so far, it's all about asynchronous composition (with 
 emphasis on both asynchronous and composition).
 I didn't see it addressing this specific problem of multiple redundant 
 updates, but I might be wrong. The truth is, this problem doesn't even exist 
 if you don't have any eager observers (i.e. when you don't ever attach any 
 ChangeListeners, and InvalidationListeners only propagate invalidation and 
 never require the value to be recomputed). The problem is, although you can 
 design your component without any eager evaluation (JavaFX bindings are 
 already composed this way), you then bind a Label.textProperty() to the end 
 of a binding chain and it all becomes eager.
 
 Regards,
 Tomas
 
 [1] https://www.coursera.org/course/reactive
 
 On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair richard.b...@oracle.com wrote:
 Have you looked at https://github.com/Netflix/RxJava by chance? I've been 
 dying to see somebody do an RxJava in JavaFX ever since devoxx and it looks 
 like you may have inadvertently started down that path :-).
 
 Richard
 
 On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
 
 On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com 
 wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called 
 and that naturally lead to thinking of try-with-resources, where 
 the resource in this case is a binding of some sort (or a wrapper 
 around a binding) that is invalidated on close() if needed.
 
 That is an interesting idea. I didn't intend blockWhile() to be safe 
 with respect to exceptions, but merely
 
 void blockWhile(Runnable r) {
   block();
   r.run();
   release();
 }
 
 Enhancement you are suggesting could be fleshed out as block() 
 returning an AutoCloseable and the usage would be
 
 try(AutoCloseable a = relaxedArea.block()) {
   obj.setWidth(w);
   obj.setHeight(h);
 }
 
 OK, done. I implemented both:
 1. added the blockWhile() method;
 2. made bindings AutoCloseable, and block() returns `this`.
 
 Tomas
 



Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-16 Thread Tomas Mikula
I had a quick look at Java 8 streams and I'm afraid they are of no use
for reactive programming. The fundamental problem is that in
java.util.stream, computation is driven by the stream consumer, rather
than the stream source, which is a complete opposite of reactive.

On the other hand, JavaFX ObservableValue doubles as a poor man's
event stream, but it would be confusing to use it as such. Not to
mention that we still want map, filter, etc... on an event stream.

Regards,
Tomas

On Mon, Dec 16, 2013 at 8:34 PM, Richard Bair richard.b...@oracle.com wrote:
 I agree, that's more of what I was thinking.

 On Dec 16, 2013, at 10:31 AM, John Smith john_sm...@symantec.com wrote:

 Perhaps reactive programming is different from the problem Tomas is solving, 
 but I think a research project which combined some of the principles of 
 functional reactive programming 
 (http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf) with 
 JavaFX properties using Java 8 lambdas and streams would be quite 
 interesting and perhaps very useful.

 John

 -Original Message-
 From: openjfx-dev-boun...@openjdk.java.net 
 [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tomas Mikula
 Sent: Monday, December 16, 2013 9:19 AM
 To: Richard Bair
 Cc: openjfx-dev@openjdk.java.net
 Subject: Re: [announce] InhiBeans: mitigate redundant recalculations

 As a matter of fact, I have. Only to the extent of the Principles of 
 Reactive Programming [1] course that is currently in progress on Coursera. 
 From what I have seen so far, it's all about asynchronous composition (with 
 emphasis on both asynchronous and composition).
 I didn't see it addressing this specific problem of multiple redundant 
 updates, but I might be wrong. The truth is, this problem doesn't even exist 
 if you don't have any eager observers (i.e. when you don't ever attach any 
 ChangeListeners, and InvalidationListeners only propagate invalidation and 
 never require the value to be recomputed). The problem is, although you can 
 design your component without any eager evaluation (JavaFX bindings are 
 already composed this way), you then bind a Label.textProperty() to the end 
 of a binding chain and it all becomes eager.

 Regards,
 Tomas

 [1] https://www.coursera.org/course/reactive

 On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair richard.b...@oracle.com 
 wrote:
 Have you looked at https://github.com/Netflix/RxJava by chance? I've been 
 dying to see somebody do an RxJava in JavaFX ever since devoxx and it looks 
 like you may have inadvertently started down that path :-).

 Richard

 On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:

 On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com 
 wrote:
 On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
 Interesting, no worse than John's pattern though.
 I thought of using a try/finally to make sure release was called
 and that naturally lead to thinking of try-with-resources, where
 the resource in this case is a binding of some sort (or a wrapper
 around a binding) that is invalidated on close() if needed.

 That is an interesting idea. I didn't intend blockWhile() to be safe
 with respect to exceptions, but merely

 void blockWhile(Runnable r) {
   block();
   r.run();
   release();
 }

 Enhancement you are suggesting could be fleshed out as block()
 returning an AutoCloseable and the usage would be

 try(AutoCloseable a = relaxedArea.block()) {
   obj.setWidth(w);
   obj.setHeight(h);
 }

 OK, done. I implemented both:
 1. added the blockWhile() method;
 2. made bindings AutoCloseable, and block() returns `this`.

 Tomas




Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-15 Thread Scott Palmer
Interesting idea.

There is a case I have been curious about and wonder what the best
practices are for it.  Suppose you have a case when you are changing
multiple different properties that will be used in a single calculation.
 You want to deal with a single change to all of them in one go.  E.g.
imagine you have an area property that is bound to both width and
height.  You want to write code like:

obj.setWidth(w);
obj.setHeight(h);

and have only ONE recalculation of the area property happen.  Currently the
way bindings work the area will be calculated twice.  The intermediate
calculation is really not a value that you ever want to observe.

Are there helpers for this sort of situation?  Are there guidelines in the
JavaFX docs somewhere?

Regards,

Scott


On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.comwrote:

 Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas



Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-15 Thread John Hendrikx
Since you are only allowed to modify properties on the JavaFX thread (in 
most cases), I've been using Platform.runLater() to make sure I observe 
only complete changes.


Basically I register an InvalidationListener on the properties that are 
relevant, and when one gets triggered I set a boolean and trigger a 
Runnable that
will be run on the JavaFX thread later (and after the change 
completes).  The Runnable checks the relevant values and acts on them, 
then resets the boolean.


I use this mechanism for example when I'm observing Objects with many 
properties that need to be stored in a database.  To make sure I only 
store consistent objects, I only observe the values of the properties 
when my own little piece of observer code runs on the JavaFX thread.  
Since nothing can modify the properties except on the JavaFX thread, 
this is almost like a form of transactions, ensuring that every change 
has completed before observing the results.


--John

On 15/12/2013 18:39, Scott Palmer wrote:

Interesting idea.

There is a case I have been curious about and wonder what the best
practices are for it.  Suppose you have a case when you are changing
multiple different properties that will be used in a single calculation.
  You want to deal with a single change to all of them in one go.  E.g.
imagine you have an area property that is bound to both width and
height.  You want to write code like:

obj.setWidth(w);
obj.setHeight(h);

and have only ONE recalculation of the area property happen.  Currently the
way bindings work the area will be calculated twice.  The intermediate
calculation is really not a value that you ever want to observe.

Are there helpers for this sort of situation?  Are there guidelines in the
JavaFX docs somewhere?

Regards,

Scott


On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikulatomas.mik...@gmail.comwrote:


Hello,

I just published a small extension of javafx bindings and properties
that can help you reduce redundant recalculations.

They provide two additional methods:

public void block();
public void release();

Call p.block() when you suspect your actions will lead to multiple
invalidations of p, and call p.release() when you are done and want to
deliver a single invalidation notification to p's observers.

https://github.com/TomasMikula/InhiBeans

Regards,
Tomas





Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-15 Thread Scott Palmer
Yes, that does the trick, but this basically means you can't use bindings
for such things.  I'm wondering if there might be an opportunity for
another enhancement similar to the block() resume() that Tomas has
implemented, but for receiving size of the notification mechanism.
 Effectively it would operate on a bound property and prevent the
re-evaluation until the resume() is called.  When resume is called the
property binding would check if it was invalidated since it was blocked and
do the appropriate recalculation.  E.g. property.blockEvaluation(),
property.resumeEvaluation(), only callable on a property that is bound.  I
haven't thought it through yet, so I'm not sure if it buys much.


Scott


On Sun, Dec 15, 2013 at 2:30 PM, John Hendrikx hj...@xs4all.nl wrote:

 Since you are only allowed to modify properties on the JavaFX thread (in
 most cases), I've been using Platform.runLater() to make sure I observe
 only complete changes.

 Basically I register an InvalidationListener on the properties that are
 relevant, and when one gets triggered I set a boolean and trigger a
 Runnable that
 will be run on the JavaFX thread later (and after the change completes).
  The Runnable checks the relevant values and acts on them, then resets the
 boolean.

 I use this mechanism for example when I'm observing Objects with many
 properties that need to be stored in a database.  To make sure I only store
 consistent objects, I only observe the values of the properties when my own
 little piece of observer code runs on the JavaFX thread.  Since nothing can
 modify the properties except on the JavaFX thread, this is almost like a
 form of transactions, ensuring that every change has completed before
 observing the results.

 --John


 On 15/12/2013 18:39, Scott Palmer wrote:

 Interesting idea.

 There is a case I have been curious about and wonder what the best
 practices are for it.  Suppose you have a case when you are changing
 multiple different properties that will be used in a single calculation.
   You want to deal with a single change to all of them in one go.  E.g.
 imagine you have an area property that is bound to both width and
 height.  You want to write code like:

 obj.setWidth(w);
 obj.setHeight(h);

 and have only ONE recalculation of the area property happen.  Currently
 the
 way bindings work the area will be calculated twice.  The intermediate
 calculation is really not a value that you ever want to observe.

 Are there helpers for this sort of situation?  Are there guidelines in the
 JavaFX docs somewhere?

 Regards,

 Scott


 On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikulatomas.mik...@gmail.com
 wrote:

  Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas





Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-15 Thread Tomas Mikula
On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer swpal...@gmail.com wrote:
 Interesting idea.

 There is a case I have been curious about and wonder what the best practices
 are for it.  Suppose you have a case when you are changing multiple
 different properties that will be used in a single calculation.  You want to
 deal with a single change to all of them in one go.  E.g. imagine you have
 an area property that is bound to both width and height.  You want to
 write code like:

 obj.setWidth(w);
 obj.setHeight(h);

 and have only ONE recalculation of the area property happen.  Currently the
 way bindings work the area will be calculated twice.  The intermediate
 calculation is really not a value that you ever want to observe.

Hi Scott,

this is precisely the problem that I'm trying to address here. Now,
the question is whether you have control over the implementation of
obj.

If yes, then it is the same case as the AND gate motivational
example from InhiBeans page. You provide a method setSize(w, h) and
use block()/release() to implement it in a way that causes only one
change of the area property.

If you cannot change the implementation of obj, what you can do is to
bind an inhibeans.binding.DoubleBinding to the area value, call it
relaxedArea, and listen to that one for all your purposes.
Then you resize obj like this:

relaxedArea.block();
obj.setWidth();
obj.setHeight();
relaxedArea.release();

Only one change of relaxedArea is emitted.

Best,
Tomas


 Are there helpers for this sort of situation?  Are there guidelines in the
 JavaFX docs somewhere?

 Regards,

 Scott


 On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.com
 wrote:

 Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas




Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-15 Thread Scott Palmer
Good stuff!   This is the sort of thing that might make a good contribution
to extend the standard Bindings class.

Scott


On Sun, Dec 15, 2013 at 5:49 PM, Tomas Mikula tomas.mik...@gmail.comwrote:

 On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer swpal...@gmail.com wrote:
  Interesting idea.
 
  There is a case I have been curious about and wonder what the best
 practices
  are for it.  Suppose you have a case when you are changing multiple
  different properties that will be used in a single calculation.  You
 want to
  deal with a single change to all of them in one go.  E.g. imagine you
 have
  an area property that is bound to both width and height.  You want
 to
  write code like:
 
  obj.setWidth(w);
  obj.setHeight(h);
 
  and have only ONE recalculation of the area property happen.  Currently
 the
  way bindings work the area will be calculated twice.  The intermediate
  calculation is really not a value that you ever want to observe.

 Hi Scott,

 this is precisely the problem that I'm trying to address here. Now,
 the question is whether you have control over the implementation of
 obj.

 If yes, then it is the same case as the AND gate motivational
 example from InhiBeans page. You provide a method setSize(w, h) and
 use block()/release() to implement it in a way that causes only one
 change of the area property.

 If you cannot change the implementation of obj, what you can do is to
 bind an inhibeans.binding.DoubleBinding to the area value, call it
 relaxedArea, and listen to that one for all your purposes.
 Then you resize obj like this:

 relaxedArea.block();
 obj.setWidth();
 obj.setHeight();
 relaxedArea.release();

 Only one change of relaxedArea is emitted.

 Best,
 Tomas

 
  Are there helpers for this sort of situation?  Are there guidelines in
 the
  JavaFX docs somewhere?
 
  Regards,
 
  Scott
 
 
  On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula tomas.mik...@gmail.com
  wrote:
 
  Hello,
 
  I just published a small extension of javafx bindings and properties
  that can help you reduce redundant recalculations.
 
  They provide two additional methods:
 
  public void block();
  public void release();
 
  Call p.block() when you suspect your actions will lead to multiple
  invalidations of p, and call p.release() when you are done and want to
  deliver a single invalidation notification to p's observers.
 
  https://github.com/TomasMikula/InhiBeans
 
  Regards,
  Tomas
 
 



Re: [announce] InhiBeans: mitigate redundant recalculations

2013-12-15 Thread Tomas Mikula
On Sun, Dec 15, 2013 at 8:30 PM, John Hendrikx hj...@xs4all.nl wrote:
 Since you are only allowed to modify properties on the JavaFX thread (in
 most cases), I've been using Platform.runLater() to make sure I observe only
 complete changes.

 Basically I register an InvalidationListener on the properties that are
 relevant, and when one gets triggered I set a boolean and trigger a Runnable
 that
 will be run on the JavaFX thread later (and after the change completes).
 The Runnable checks the relevant values and acts on them, then resets the
 boolean.

Hi John,

this approach works fine if the effects of the Runnable run later are
not observable to the client code.
In most cases though, it is reasonable to expect the following
assertion to hold:

obj.setWidth(w);
obj.setHeight(h);
assert obj.getArea() == w*h;

Regards,
Tomas


 I use this mechanism for example when I'm observing Objects with many
 properties that need to be stored in a database.  To make sure I only store
 consistent objects, I only observe the values of the properties when my own
 little piece of observer code runs on the JavaFX thread.  Since nothing can
 modify the properties except on the JavaFX thread, this is almost like a
 form of transactions, ensuring that every change has completed before
 observing the results.

 --John


 On 15/12/2013 18:39, Scott Palmer wrote:

 Interesting idea.

 There is a case I have been curious about and wonder what the best
 practices are for it.  Suppose you have a case when you are changing
 multiple different properties that will be used in a single calculation.
   You want to deal with a single change to all of them in one go.  E.g.
 imagine you have an area property that is bound to both width and
 height.  You want to write code like:

 obj.setWidth(w);
 obj.setHeight(h);

 and have only ONE recalculation of the area property happen.  Currently
 the
 way bindings work the area will be calculated twice.  The intermediate
 calculation is really not a value that you ever want to observe.

 Are there helpers for this sort of situation?  Are there guidelines in the
 JavaFX docs somewhere?

 Regards,

 Scott


 On Sat, Dec 14, 2013 at 11:54 PM, Tomas
 Mikulatomas.mik...@gmail.comwrote:

 Hello,

 I just published a small extension of javafx bindings and properties
 that can help you reduce redundant recalculations.

 They provide two additional methods:

 public void block();
 public void release();

 Call p.block() when you suspect your actions will lead to multiple
 invalidations of p, and call p.release() when you are done and want to
 deliver a single invalidation notification to p's observers.

 https://github.com/TomasMikula/InhiBeans

 Regards,
 Tomas