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?
