On 3/21/08, Brendan Eich <[EMAIL PROTECTED]> wrote: > > I believe the intention among the core ES4 group over the last couple > of years has been to support runtime qualifiers in ES4, as well. JS > has computed property names since day 1: o[id] to access o.p. An > optional strict mode can't reason about these, but they aren't the > only loophole (eval, with, global non-fixtures). Why rule out runtime- > computed qualified names (with either part computed at runtime)?
I'm talking about lexical bindings. I agree with you about object properties; computed names are already the norm. For lexical bindings, the situation (if I understand it correctly) is different. Because of the way eval is actually implemented in current engines, it's impractical (or maybe strictly impossible?) to resolve lexical lookups ahead of time. With ES4, though, only the operator form of eval will be able to modify lexical environments, and its use can be statically detected. Any environments that can be affected by the eval operator can be known at compile time, and they can use slow lookup. The same holds for with statements. And, I think, the same would hold for runtime qualified names... but do you really want to add another way to defeat compile time lookup? I kind of got the impression that if there were no question of breaking the web, you would get rid of with (in its current, dynamic scoping form) and eval's ability to modify local environments. -Jon _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
