[lively-kernel] data binding setters / why no infinite recursion?

[Robert Krahn]

The criticism is justified, the naming is confusing. While implementing we
found out that the mechanism is more general than we first thought but
never changed the names. The next time we swipe over it we'll improve it :)
Thanks for the feedback!

On Mon, Sep 15, 2014 at 5:02 PM, Davide Della Casa <davidedc at gmail.com>
wrote:

> indeed had just traced through it.
>
> For future Google searchers: it’s the “isActive” flag of the
> AttributeConnection.
>
> It’s set at “this.isActive = true;” in the update method.
>
> Update causes the setter in F to go to work. the setter in F calls the
> updater of C, but here we stop because we check the flag we set before.
>
> (I’m short on time now, if I had the time I’d mark that flag to be
> explained in the code)
>
>
>
> On separate note, targetProp/targetMethod turn loosely into each other:
>
> *   initialize: function(source, sourceProp, target, targetProp, spec)*
>
> should probably be something like
>
> *   initialize: function(source, sourceProp, target, targetPropOrMethod,
> spec)*
>
> and the ambivalence of that value “*targetPropOrMethod* “ should be
> probably propagated through, it seems that the naming “picks” one or the
> other value a little randomly along the code, e.g. in init function:
>
> *    this.targetMethodName = targetProp;*
>
> which seems strange, at least to me.
>
> Cheers,
> Davide Della Casa
>
> On 16 Sep 2014, at 00:39, Lars <lars.wassermann at googlemail.com> wrote:
>
> Hi Davide,
>
> The trick is somewhere in the binding activation. The implementation
> prevents the same connection to be triggered twice in the same scope. So
> changing C updates F updates C, but then the recursion stops. You can still
> run into infinite loops if you use asynchronous updater, afaik. But most of
> the base cases should be covered by that simple change of semantics.
>
> Best,
> Lars
>
> On 15 September 2014 16:10, Davide Della Casa <davidedc at gmail.com> wrote:
>
>> In the Celsius - Fahrenheit example, each text box is connected to the
>> other one.
>>
>> So changing the Celsius calculates the Fahrenheit and vice-versa.
>>
>> Question is: why does it not go in infinite updates between the two text
>> boxes?
>>
>> I’m going through the code and “How connect works” and can’t figure out
>> what’s preventing the infinite updates. The original Ingalls 1988 Fabrik
>> paper mentions that this loop can/should/is avoided but it doesn’t give
>> specifics (“with some care” and “bidirectionality…shorthand for multiple
>> paths” page 5). There doesn’t seem to be a check in “connect” or “update”
>> or the setter. The setter seems to do an update, so why doesn’t changing
>> the C box cause the setter of F to invoke updates on C again?
>>
>> Also tried to look for “loop” in source code
>> https://github.com/LivelyKernel/LivelyKernel/search?utf8=%E2%9C%93&q=loop&type=Code but
>> nothing jumps to the eye.
>>
>> What’s the trick I’m missing?
>>
>> (BTW the edit/select/move-cursor behaviour in the text boxes when they
>> are connected is glitchy)
>>
>> Cheers,
>> Davide Della Casa
>>
>>
>>
>> _______________________________________________
>> lively-kernel mailing list
>> lively-kernel at hpi.uni-potsdam.de
>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>
>>
>
>
> _______________________________________________
> lively-kernel mailing list
> lively-kernel at hpi.uni-potsdam.de
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20140916/6bcae8ce/attachment.html>