[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?


Reply via email to