- From: timeless <timeless@gmail.com>
- Date: Fri, 11 Feb 2011 06:33:57 +0200
On Fri, Feb 11, 2011 at 5:51 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > I don't think so. ?If there is any parse or compilation or whatever you want > to call it error, the script is never executed, so window.x is never > defined. oops, right, but i don't know that that complicates things much. you just store a list of variables to pollute window with when </script> should be applied or the error to send to window.onerror at </script> time. > Also, I would fully expect it to be a web compat requirement that > window.onerror not be triggered until the script would be evaluated. ?If you > parse/compile/whatever before that and hit an error, you'd need to save that > and report it at the "right" time. sure, but that's one error to store with a pending <script> it's cheaper than most other things. any attempt to speculatively compile or compile on a thread will have to support queuing the window assignments / onerror dispatch. > Which means the that parse/compile/whatever process is currently not > observable directly. ?And that's a good thing! agreed >> in theory, i believe a js engine could choose to discard all work it >> has done to validate syntax for x+y beyond saving those coordinates, >> and then either do the proper ast / bytecode / machine code generation >> lazily (or schedule to do it on a thread). > > Sure; a js engine could also not do any syntax validation at all, until it > needs to run the script... my operative assumption is that the scripts we're dealing with have lots of functions which are declared but which will not be used in a given page instance, which means that there /could/ be a win in not performing a complete compile, both in time and space. obviously any changes to the engines increases complexity which is a loss of sorts.
Received on Thursday, 10 February 2011 20:33:57 UTC