One more thought:
I'm all for adding more pragmas but I wish there was a way to set them
in LZX, e.g. http://jira.openlaszlo.org/jira/browse/LPP-8763
Regards,
Max Carlson
OpenLaszlo.org
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.
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.)
2) Add a global #pragma that developers can use to enable the constraint
warnings.
3) Add a local #pragma to turn off the warning on a per-constraint basis. An "I
know what I am doing" flag.
4) Add the<dependencies> tag so developers can (a little more easily) write
custom dependency functions
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).
Comments? Other ideas?
