Strict mode eval code cannot instantiate variables or functions
in [JavaScript]
|
Prev: seethis VERY DIFFERENT
Next: regex help?
From: Dmitry A. Soshnikov on 5 Dec 2009 06:45 On Dec 5, 12:06 am, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > > Should be `false`, abstractly it looks like: > > > // global's LE > > LexicalEnvironment = { > > outer: null, > > EnvironmentRecord: { > > v: true > > } > > > } > > > // eval's LE > > LexicalEnvironment = { > > outer: globalLE, > > EnvironmentRecord: { > > v: false > > } > > > } > > > // anonymous FE > > LexicalEnvironment = { > > outer: evalLE, > > EnvironmentRecord: {} > > > } > > Thank you for response. If i properly understood you answer, internal > [[scope]] property of anonymous function expression refer > `EnvironmentRecord` created from eval lexical environment. So i can > form *closure* in this way in code passed to `eval'. > > var global = this, f; > eval([ > '"use strict";', > 'global.f = function(){', > '/*function body*/', > '};' > ].join('')); > window.alert(f); Yep, sure this way it should be possible as a closure. ;) /ds
From: abozhilov on 5 Dec 2009 07:35 Dmitry A. Soshnikov wrote: > Yep, sure this way it should be possible as a closure. ;) Ok.The last question is. How determinate `this' value in `LexicalEnvironment` created from eval in strict mode of ECMA5 implementations? Another thing is, how can do it similar behavior of `eval' in ECMA3 implementations: - Create new execution context for eval code. - Create VO for variable instantiation to eval code. - Scope Chain contain AO/VO associated with created execution context for eval code, followed by AO/VO of calling execution context. - This value. Here we have two alternative. a) this refer Global Object b) this value can inherit from calling execution context this value. All of that we can do it, with wrapping eval calling in function expression: var v; (function(){ eval([ 'var v = 10;', 'window.alert(v);', //10 'window.alert(this);' //refer to Global Object ].join('')); }()); window.alert(v); //undefined Inherit this value from calling execution context: var v; (function(){ eval([ 'var v = 10;', 'window.alert(v);', //10 'window.alert(this);' //refer to object reffered from `this' in calling execution context ].join('')); }.call(this)); window.alert(v); //undefined
From: Dmitry A. Soshnikov on 5 Dec 2009 08:10 On Dec 5, 3:35 pm, abozhilov <fort...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > > Yep, sure this way it should be possible as a closure. ;) > > Ok.The last question is. How determinate `this' value in > `LexicalEnvironment` created from eval in strict mode of ECMA5 > implementations? > > Another thing is, how can do it similar behavior of `eval' in ECMA3 > implementations: > > - Create new execution context for eval code. > - Create VO for variable instantiation to eval code. > - Scope Chain contain AO/VO associated with created execution context > for eval code, followed by AO/VO of calling execution context. > - This value. Here we have two alternative. > a) this refer Global Object > b) this value can inherit from calling execution context this value. > > All of that we can do it, with wrapping eval calling in function > expression: > > var v; > (function(){ > eval([ > 'var v = 10;', > 'window.alert(v);', //10 > 'window.alert(this);' //refer to Global Object > ].join(''));}()); > > window.alert(v); //undefined > > Inherit this value from calling execution context: > > var v; > (function(){ > eval([ > 'var v = 10;', > 'window.alert(v);', //10 > 'window.alert(this);' //refer to object reffered from `this' > in calling execution context > ].join(''));}.call(this)); > > window.alert(v); //undefined Yep, behavior of providing `ThisBinding` (that's how it called now) the same including strict mode for the eval, so it will be or global object or borrowed from the calling context. /ds
From: Lasse Reichstein Nielsen on 5 Dec 2009 08:42 "Dmitry A. Soshnikov" <dmitry.soshnikov(a)gmail.com> writes: > Yeah, already discussed regarding ECMA-262-3. And nevertheless, > implementation of Spidermonkey (and other newer *monkeys) still seems > to me more logical (e.g. for if-else statements) regardless > specification. I don't see the big sense in words they say "an > ExpressionStatement cannot start with the `function` keyword because > that might make it ambiguous with a FunctionDeclaration"? If it's in > statement position let's treat is as special FD which won't be created > on entering the context, but in runtime like FE and let's call it > Function Statement (FS). What would be the scope of the name introduced by this function statement? Would it, essentially, be a shorthand of: var name = function name(args) { body }; or var name = function(args) { body }; If so, why not use that? /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Dmitry A. Soshnikov on 5 Dec 2009 11:15
On Dec 5, 4:42 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> writes: > > > Yeah, already discussed regarding ECMA-262-3. And nevertheless, > > implementation of Spidermonkey (and other newer *monkeys) still seems > > to me more logical (e.g. for if-else statements) regardless > > specification. I don't see the big sense in words they say "an > > ExpressionStatement cannot start with the `function` keyword because > > that might make it ambiguous with a FunctionDeclaration"? If it's in > > statement position let's treat is as special FD which won't be created > > on entering the context, but in runtime like FE and let's call it > > Function Statement (FS). > > What would be the scope of the name introduced by this function > statement? > Suggest the same as for `FD` and `var`, the only difference is that such function objects will be created conditionally in runtime. > Would it, essentially, be a shorthand of: > var name = function name(args) { body }; > or > var name = function(args) { body }; > If so, why not use that? > That's another question "why not use that?". Sure we can. The same can be asked - why not use `FS` suggested by Gecko? /ds |