[announce] InhiBeans: mitigate redundant recalculations

[Tomas Mikula]

On Mon, Dec 16, 2013 at 7:56 AM, Tom Eugelink <tbee at 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.mikula at gmail.com>wrote:
>>
>>> On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer <swpalmer at 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.mikula at 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
>>>>
>>>>
>
>