On 2010-04-11, at 16:48, André Bargull wrote:
> 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>
What is the expectation for constraints? That they work most of the time for
some expressions? Is it really more mysterious to get a warning that your
constraint will not track certain changes than to have your constraint silently
fail?
Clearly, if we want to allow general expressions in constraints but also warn
the user when the expression is too complex for our simple dependency
implementation to figure out what they mean, we need to provide a way for the
user to explicitly enumerate the constraints. For the most general case, we
already have a solution: you write a method that updates the attribute, and
you use <handler> clauses to attach that method to all the relevant events.
For the simple case of constraining one attribute to a pure function of another
set of attributes, the ${} shorthand and our dependency analyzer suffice. The
middle ground is what is not covered. Here's an idea that would handle your
case above: we provide a way to write your constraint as two parts: the values
you want to 'listen' to, and the computation you want to make when those values
change. Perhaps something like:
<text text="$(group1.value){'DE: ' + group1.value + ' -> ' +
translation.de[group1.value]}" />
<text text="$(group1.value){'IT: ' + group1.value + ' -> ' +
translation.it[group1.value]}" />
The semantics are: if the 'when' part of the constraint is a parenthesized
expression, the dependency analysis is on that expression, and when any of
those values changes, the full expression is evaluated to update the attribute.
For multiple dependencies, you specify a comma-separated list.
> 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.
Reasonable. Hard to implement, but I think it could be done.
> 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.)
> - ...
<dependencies> would define a method, just as <setter> does, so you would have
standard inheritance and method combination (and the inherent risk that the
programmer might override one and not the other of the method/dependency pair
and screw themselves. It would be an expert part of the system that would need
to be used with care.
> 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.
I don't quite see how a Debug warning 'breaks' a user program. When debugging
is off, the warnings go away and the change as proposed implements swf8
compatibility for swf9/10, so this is a net improvement IMO.
The other thing we have done in the past when introducing a new warning like
this is to make it an INFO-level warning, and tell people who want backward
compatibility to set Debug.messageLevel to 'WARNING'. This allows people to
incrementally address the new messages.
I think, in order to move forward with this change (and not have the good parts
of it held up by theoretical proposals), I will just disable all the new
warnings in the change and not update any components. I'll make a separate
proposal for enabling the warnings and how to address them.
Thanks for your input.
