[Laszlo-dev] For Review: Change 20100409-ptw-7 Summary: Make constraints and dependencies more debuggable and compatible

[Max Carlson]

On 4/11/10 5:22 AM, P T Withington wrote:
> [Adding Laszlo-Dev because of the wider issues raised here.]
>
> On 2010-04-10, at 09:03, André Bargull wrote:
>
>> In my opinion this change set tries to handle too much. It should be sufficient to handle the original error when there is no dependencies method for a function and just ignore any error in swf9+, similar to the swf8 and dhtml behaviour. For example the changes to the components introduce too much internal stuff, I don't think we want to introduce things like "$lzc$funcName_dependencies" into user-land (I consider all components as user-land!).
>
> See my proposal in response to Max regarding introducing a new<dependencies>  tag.  I don't think we want to rely on luck to have our constraints work, so I think this warning at least has use to core developers.

I agree with André that we should preserve the dhtml/swf8 behavior in 
non-debug mode by ignoring errors in swf9+.

Overall, I'm torn because it's always good to warn about potential 
issues when we can.  But, the proposed fixes do seem to require a 
developer to know a lot about event system internals.

This this could cause us to spend a bunch of time maintaining/updating 
old components and demos that have been working 'just fine.'  I can 
imagine other developers feeling that way.

>> And searching for functions in constraints in the demo and docs directory gives these results:
>> - parseFloat(..)
>> - Number(..)
>> - thumbControl(..)
>> - getEventColor(..)
>> - formatToString(..)
>> - escapeText(..)
>> ...
>>
>> None of these functions is currently handled. And you don't want to add more exception rules for the compiler resp. handcrafted dependencies methods, do you?
>
> Good question.  Possible answers (not mutually exclusive):
>
> 1) Preserve the status quo.  Just turn off the warning about function dependencies.  (I would keep the property-depencencies warning because it has a simple work-around, change your constraint from $always to $once; or if you really are expecting to track a non LzEventable value, propose an improvement to make that value trackable.)

This seems like step backwards.

> 2) Add a global #pragma that developers can use to enable the constraint warnings.

This seems important.

> 3) Add a local #pragma to turn off the warning on a per-constraint basis.  An "I know what I am doing" flag.

We can go through and file improvements, adding pragmas where needed to 
leave old components/demos as-is.  It's better to know about potential 
issue(s) even if they're relatively low priority.

> 4) Add the<dependencies>  tag so developers can (a little more easily) write custom dependency functions

This would help, but how will developers determine what to put in the 
function?  Perhaps the warnings can list the dependencies the compiler 
found as a suggestion.

> 5) Add more exceptions to the compiler, although technically the exceptions that I add in this change are not 100% accurate (no amount of static analysis in ES3 can prove that `Math.round`, etc. have not been shadowed or rebound).

Should we make it possible to add constraint function exceptions in LZX, 
e.g. to add an exception formatToString()?

> Comments?  Other ideas?