1

Writing the following will result in the evaluation of the Function constructor function, resulting in the presence of a property on the global object pointing to a function-object instance Foo.

function Foo() {}

Execution contexts are created when functions are invoked, hence has an execution context other than the global one been created even without invocation of Foo?

My thinking is as follows:

Everything is an object in JavaScript (with minor exceptions related to primitives). Objects are created by functions. Foo is an object. A function has been invoked.

Ben Aston
  • 53,718
  • 65
  • 205
  • 331
  • how do you know if it has been created? Citations? – Amit Joki Nov 30 '14 at 15:14
  • Please see my earlier question: http://stackoverflow.com/questions/27214456/execution-contexts-in-javascript/27214701#27214701 – Ben Aston Nov 30 '14 at 15:14
  • 3
    No execution context has been created since no function has been invoked. When you invoke `Foo` a new execution context will start. – Benjamin Gruenbaum Nov 30 '14 at 15:15
  • 2
    `function Foo() {}` is a declaration, not an invocation, so why do you expect that an execution context would be created here? There's no invocation. – Matt Ball Nov 30 '14 at 15:15
  • Per my understanding a function has been invoked behind the scenes: `Function`. – Ben Aston Nov 30 '14 at 15:16
  • 1
    Your understanding is incorrect, no function has been invoked behind the scenes - `Function` is used for dynamically created functions - the above code only has a function declaration. Moreover - even if the engine did allocate a context (no engines I've read do) - it would be invisible to you. – Benjamin Gruenbaum Nov 30 '14 at 15:17
  • Everything is an object in JavaScript (with minor exceptions related to primitives). Objects are created by functions. Foo is an object. A function has been invoked. – Ben Aston Nov 30 '14 at 15:17
  • @torazaburo Haha, because I want to understand the minutiae of JavaScript. And thank you for confirming that a function is invoked. – Ben Aston Nov 30 '14 at 15:20
  • @Ben his "confirmation" is incorrect though. In practice no reasonable JS engine would do that. – Benjamin Gruenbaum Nov 30 '14 at 15:21
  • 1
    You should probably distinguish between the actions visible to the programming environment, and the actions mandated by the ECMAscript spec to dictate key implementation details of that programming environment. Things like the `Function` constructor are part of the latter. If there is an execution context involved there, it disappears before you as the programmer ever see it, and it's not related to the execution context of the function `Foo` when `Foo()` is invoked. – Jason S Nov 30 '14 at 15:25
  • @BenjaminGruenbaum OK, so the answer to this question is that conceptually, we can think of a new function-object being instantiated by the code through the invocation of a function (the `Function` constructor function), but that implementations optimize this away. – Ben Aston Nov 30 '14 at 15:25
  • Not really, conceptually execution contexts are relevant to what variables are available when a function is run and its `this` value and the sorts - none of that is relevant here anyway. Also - not all objects are created by functions for example `{x:3}` or `/hello/g` – Benjamin Gruenbaum Nov 30 '14 at 15:26
  • @JasonS Can you tell me whether engine implementations will actually invoke the `Function` constructor function in the code in the question, or whether this is a convenient cognitive shorthand, or neither? – Ben Aston Nov 30 '14 at 15:26
  • @BenjaminGruenbaum that is totally wrong. `{x:3}` is roughly equivalent to `var o = new Object(); o.x = 3;`. The `Object` constructor function is invoked. Similarly for the regex literal syntax. – Ben Aston Nov 30 '14 at 15:27
  • 1
    "Equivalent to" is not the same as "the same as." – Matt Ball Nov 30 '14 at 15:29
  • Two things being equivalent doesn't mean or even imply that they happen the same way - just like `1+3` and `4` are both equal but one involves addition and the other does not. The specification is even clear about this - saying it is created __as if__ Object is called - explicitly stating a call is not actually required. I'm not in front of the spec but I'd put my money on 11.1.5 "Object Initializer" (although it might moved since) – Benjamin Gruenbaum Nov 30 '14 at 15:30
  • So there is a category of object instantiations that is internal to the JavaScript engine that do not abide by the same rules as user object instantiations? – Ben Aston Nov 30 '14 at 15:37
  • The thing is - the engine can instantiate object literala any way it wants as long as there are no observable side effects. I'm general since you can't observe execution contexts directly the engine can omit allocating them or even not have any execution contexts at all! As long as the behavior you see as a programmer stays the same. – Benjamin Gruenbaum Nov 30 '14 at 15:41
  • Why down vote this question? It is cogent and coherent and about programming. What more do I need? – Ben Aston Nov 30 '14 at 16:11

1 Answers1

0

Answering my own question, based on the long comment list above.

No execution context is created because execution contexts are only meaningful for user-defined code. For the internal operation of a JavaScript engine, such as the precise mechanism for the creation of the function-object Foo in the code in the question, are left to engine implementers.

Ben Aston
  • 53,718
  • 65
  • 205
  • 331