[Laszlo-dev] Constraint ordering and initial values [Was: For Review: Change 20090511-bargull-Yq7 Summary: constraint returns NaN in resizestatemin]

[Henry Minsky]

On Mon, May 11, 2009 at 10:40 AM, P T Withington <ptw at pobox.com> wrote:

> I'm concerned that my r13731 change that sets the initial value of
> constrained attributes to `undefined` rather than `null` may have more
> fallout.  This change by André fixes one instance, but there could be many
> more lurking.
>
> The issue:  Constraints run in random order.  Constraints that depend on
> attributes that are themselves constrained may reference those attributes
> when they are still undefined.  When used in a numeric expression, undefined
> coerces to NaN.  NaN's are "sticky", hence may pollute other attributes, and
> the constraint system may never recover.
>

Yeah, I think that not only will we find that some existing code has gotten
 broken, but people will also get into trouble in the future with NaNs.
 Maybe we should have a way to ensure that all attributes have a defined
default value?


> r13731 was an attempt to make events fire less often by not having them
> fire when a constraint updated an attribute to the value it already had.  To
> do this I needed a sentinel value that indicated that the attribute had
> _never_ been updated (to distinguish the case where a constraint was setting
> the attribute to `null`).  `undefined` seemed to fit that bill, but clearly
> it has additional consequences, as seen in LPP-8088.
>
> I'm looking for a way to achieve the optimization of 13731 without the NaN
> hazard.  I think this means that we have to revert to storing `null` as the
> initial value of constrained attributes (even better would be to store some
> type-correct equivalent of null).  And we'll have to have some sort of a
> flag that says you always send the event the first time around (e.g., when
> called from __LZapplyArgs).



 That sounds like a reasonable approach; the optimization holds in normal
use, but when the setter gets run the first time it always fires.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20090511/50a1f943/attachment.html