On 2010-04-08, at 17:07, André Bargull wrote: > On 4/8/2010 12:27 AM, Max Carlson wrote: >> On 4/7/10 1:52 PM, P T Withington wrote: >>> On 2010-04-07, at 16:23, Max Carlson wrote: >>> >>>> On 4/7/10 12:58 PM, P T Withington wrote: > [...] >> >>> Finally, we can't do it only for debug mode unless you want the >>> situation that started me down this path -- the user who complained >>> that his app works in debug mode (which catches and neuters all >>> errors) but fails when he turns off debugging. I think we want to >>> always catch and ignore these errors (because that is the LZX way, >>> inherited from swf8). We just need to decide if we _always_ want to >>> warn about these, or if we want a special 'debug constraints' mode >>> that turns on these warnings. >> >> Right, got it. > > I disagree with Tucker. I think we want to propagate this development style: > First write the application and run it in debug mode, then resolve all errors > reported in the debugger and finally test and deploy your application in > non-debug mode. > Therefore non-debug code should be made as fast as possible, only debug code > should catch errors and provide users with appropriate (!) messages to find > the errors and give hints how to handle them. > For example the following application works perfectly in swf8 (debug and > non-debug mode), but it fails for swf9+/dhtml in non-debug mode. So Tucker's > statement about "always catch and ignore .. errors" isn't even our current > development strategy. > > <canvas> > <script>(new Object).bla();</script> > <text>This text is only created if the script error is handled</text> > </canvas>
Ok, I was being sloppy talking about what errors are ignored. I agree that we want to minimize overhead in non-debug mode, but there are also some behaviors that are expected to work, because of our dynamic heritage, even in the face of errors. In particular, because our constraint system is very simplistic, we hide many cases where the dependency computation generated by the compiler is just wrong. We are _trying_ to not fail in the case of functions that do not have dependency methods, but we presently fail to cover the case of a method on a sealed object. There is no way to test for the presence of a dependency function for such a method in as3 that I know of other than trying to fetch it and catching the corresponding type error when it is not there. If we want to be efficient, we should create a list of all the built-in Javascript methods that we _know_ do not have dependency methods, so we don't even try to look for them (it looks like someone started such a project -- the ReferenceCollector has an `immutableProperties` list, but it is never consulted). >>>>> The question is: when you constrain to function that does not have a >>>>> dependencies method, should you get a warning (because you might >>>>> wonder why your constraint does not update) or should it silently >>>>> succeed (because that is what happens in swf8 and DHTML right now)? >>>> >>>> It seems like you might want to be able to constraint to arbitrary >>>> functions and have the event system default to lz.Idle.onidle as a >>>> dependency. There should still be a warning in debug mode, so folks >>>> know to update this for efficiency. >>> >>> I would rather make there be a way for people to write the dependency >>> method for an arbitrary function. >> >> Sounds fair. I'll file an improvement for this. > > 1+ for the improvement request. > > Concerning Tucker's initial question whether constraints to function without > a dependencies method should generate a warning: > I've attached a lzx-application which demonstrates the usage of <mediastream> > and <videoview>. The application uses a simple class (<ftext>) to show > formatted text. In that <ftext> class, a constraint on a "_format()" method > is created, "_format()" works as a trampoline for the inherited > "formatToString()" method. [Off-topic: Maybe we should revisit this discussion: http://www.openlaszlo.org/pipermail/laszlo-user/2007-July/005765.html and build something in to <text> so you don't need your workaround?] > In this use case I don't want to see any warnings. (And neither a dependency > to onidle.) This seems to be the expected behaviour, too. If you search for > /\${[^}]*[a-zA-Z]+\([^}]*}/ in the components directory, you'll get over 60 > hits. Inspecting these constraints reveals that many of them use functions of > the Math object. And the Math object clearly doesn't have any dependencies > methods. > (If you wonder why I needed to add the "_format()" method, well, guess what > happened in swf9+ when I used this constraint > "${this.formatToString.apply(...)}" ;-) ) OTOH, if you created a constraint where there was a function that _does_ have dependencies, would you want a warning then? If there were a way to declare new dependency methods, then you could presumably declare a 'null' one somehow. >>>>> Also, while trying to make the error message that you get more >>>>> useful (by telling you which constraint it is that is not getting >>>>> its dependencies right), I notice that we get a pile of "failed" >>>>> dependencies already, that are just silently ignored. These seem to >>>>> come from dependencies that perhaps are evaluated too soon and hence >>>>> the context of the event they want to listen to does not yet exist. >>>>> It seems we might want to get a warning on those too? >>>> >>>> That would be great! >>> >>> Again, the question is whether we want to do this always, or have a >>> mode for it. >> >> It sounds like there should be a mode for this to keep from being >> flooded by warnings - but that could be added as an improvement later, >> perhaps with the special 'debug constraints' mode you mentioned above. > > Without further information about the failed constraints, I'd say that any > constraint with an invalid reference should be reported as an error to the > user. But sometimes sloppy dependencies methods are expected by the users, > see LPP-6594... > <LPP-8850.lzx> Indeed.
