[Laszlo-dev] For Review: Change 20100409-ptw-7 Summary: Make constraints and dependencies more debuggable and compatible

André Bargull andre.bargull at udo.edu
Sun Apr 11 13:48:49 PDT 2010


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


More information about the Laszlo-dev mailing list