1) Do we want to support the following programming style? In that case
property-depencencies warnings aren't useful. (Think of 'translation'
being a JSON object, so the example is more meaningful..)
<canvas debug="false" layout="axis:y">
<script when="immediate">
var translation = {
'de': {'true': 'wahr', 'false': 'falsch'},
'it': {'true': 'vero', 'false': 'falso'}
}
</script>
<radiogroup id="group1">
<radiobutton text="true" selected="true"/>
<radiobutton text="false"/>
</radiogroup>
<text text="${'DE: ' + group1.value + ' -> ' +
translation.de[group1.value]}"/>
<text text="${'IT: ' + group1.value + ' -> ' +
translation.it[group1.value]}"/>
</canvas>
2+3) Maybe it'd be more useful to set this 'constraint warning' flag per
each compilation unit. Let's say you use a components library from a 3rd
party, the library is delivered as a lzo. Now you're enabling the global
flag to show constraint warnings to help cleaning up _your_ code, but
suddenly thousand of warnings show up from the components library code,
because the components' author was sloppy when writing constraints. You
have no access to the components' source code, so you're stuck with
disabling the flag again, since all those components' warnings make
debugging your code impossible.
4) Sounds good. Would it be possible to use this <dependencies> tag for
attributes, too? That'd make it possible to define in the example from
above, that only "group1.value" needs to be tracked.
What happens when methods are overwritten in subclasses?
- Do you need to write new <dependencies> for the new methods? (The old
dependencies may be completely useless for a changed method.)
- Are <dependencies> inherited from the superclass? Can you manually
call the inherited dependencies method? (Counterpart of the previous
question: old dependencies may be still useful.)
- Is it possible to restrict inheritance for <dependencies>?
(Combination of the two previous questions: you can decide whether old
dependencies are still useful.)
- ...
5) I don't like that approach because of the reasons you've addressed.
My personal opinion:
Until it's possible to give users more control about function
dependencies and constraint dependencies in general, we should try to
preserve backward compatibility in swf9+, that means ignore errors like
in swf8/dhtml. Maybe not the best solution, but at least it guarantees
that user applications don't break.
On 4/11/2010 2:22 PM, 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?
