Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #26465 > unrolled thread

Can somebody explain this to me

Started by"Tony Johansson" <johansson.andersson@telia.com>
First post2015-01-06 00:48 +0100
Last post2015-01-08 11:33 +0100
Articles 10 on this page of 70 — 10 participants

Back to article view | Back to comp.lang.javascript

Contents

  Can somebody explain this to me "Tony Johansson" <johansson.andersson@telia.com> - 2015-01-06 00:48 +0100
    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-06 01:40 +0100
      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-06 16:01 +0000
        Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-06 17:26 +0100
          Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com> - 2015-01-07 00:45 -0200
            Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-07 04:35 +0100
              Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-01-07 16:15 -0200
                Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-07 21:20 +0100
                  Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 00:00 +0100
                    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 00:09 +0100
                      Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 10:53 +0100
                        Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 16:17 +0100
                          Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 17:04 +0100
                            Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 19:02 +0100
          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-07 15:37 +0000
            Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-07 17:01 +0100
              Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-08 10:43 +0000
                Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 13:16 +0100
            Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 16:43 +0100
              Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-09 20:16 +0000
                Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-09 22:11 +0100
                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-10 16:58 +0000
                    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-11 12:41 +0100
                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-12 15:46 +0000
                        Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-12 18:01 +0100
                          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-13 10:38 +0000
                          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-14 16:06 +0000
                Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-21 13:00 -0800
                  Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com> - 2015-01-21 20:53 -0200
                    Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-22 11:43 +0000
                      Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-01-22 10:20 -0200
                        Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-23 19:42 +0000
                    Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-28 18:14 +0100
                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-22 11:39 +0000
                    Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-22 13:27 +0100
                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-23 14:36 +0000
                        Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-23 08:51 -0800
                          Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-23 23:17 +0100
                          Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-24 16:42 +0000
                            Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-24 15:35 -0800
                              Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-25 11:08 +0000
                                Re: Can somebody explain this to me "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-01-26 08:33 -0800
                                Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-27 14:10 +0100
                                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-28 15:50 +0000
                                    Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-28 18:26 +0100
                                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 10:29 +0000
                                        Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-31 00:37 +0100
                                    Re: Can somebody explain this to me "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-01-28 13:30 -0800
                                      Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-28 22:40 +0100
                                        Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 10:32 +0000
                                      Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 10:23 +0000
                                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-29 11:04 +0000
                              Re: Can somebody explain this to me "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-01-26 08:21 -0800
                                Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-26 11:10 -0800
                    Re: Can somebody explain this to me Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-22 06:36 -0800
        Re: Can somebody explain this to me Tim Streater <timstreater@greenbee.net> - 2015-01-06 17:34 +0000
          Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-06 19:03 +0100
            Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-07 15:07 +0000
              Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-07 16:41 +0100
                Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-07 17:22 +0100
                  Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-08 10:36 +0000
                    Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 13:36 +0100
                      Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 17:54 +0100
                        Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 19:48 +0100
                          Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 22:09 +0100
                        Re: Can somebody explain this to me Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-01-08 18:22 -0200
                          Re: Can somebody explain this to me "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-08 22:13 +0100
                          Re: Can somebody explain this to me Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-08 22:25 +0100
                Re: Can somebody explain this to me John Harris <niam@jghnorth.org.uk.invalid> - 2015-01-08 10:25 +0000
                  Re: Can somebody explain this to me "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-08 11:33 +0100

Page 4 of 4 — ← Prev page 1 2 3 [4]

#26493

FromJohn Harris <niam@jghnorth.org.uk.invalid>
Date2015-01-08 10:36 +0000
Message-ID<66nsaal9kcls42elbn16dkbv3fiille47o@4ax.com>
In reply to#26485
On Wed, 07 Jan 2015 17:22:40 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:


  <snip>
>But ISTM that John still has not realized that I did _not_ recommend to 
>write *all* opening braces of functions on the same line as the “function” 
>keyword, but only those of function *expressions*; and that indentation does 
>not enter into it (you can and should indent the function body with either 
>form).  

Of course I realised. That's why I said that a function expression is
signalled by "= function ".


>It is because, as is obvious from the above, he has not realized yet 
>that there are (at least) two ways to “define” a function in ECMAScript, of 
>which one includes a *declaration*.

Both ways create a function object. One way gives it a global name,
the other need not. What else matters?

  John

[toc] | [prev] | [next] | [standalone]

#26496

From"Christoph M. Becker" <cmbecker69@arcor.de>
Date2015-01-08 13:36 +0100
Message-ID<m8ltkq$rq3$1@solani.org>
In reply to#26493
John Harris wrote:

> On Wed, 07 Jan 2015 17:22:40 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> 
>> It is because, as is obvious from the above, he has not realized yet 
>> that there are (at least) two ways to “define” a function in ECMAScript, of 
>> which one includes a *declaration*.
> 
> Both ways create a function object. One way gives it a global name,
> the other need not. What else matters?

Most importantly scope rules.  A function declaration creates a function
object that is passed in the *variable* environment of the running
execution context as environment; a function object that is created by a
function expression is passed in the *lexical* environment.  Informally,
one might say that function declarations are "hoisted".

Another pitfall that one should be aware of is that the behavior of a
function expression in a statement context is standardized, while the
behavior of a function declaration (better called function statement
here) in a statement context is not, even though it is allowed in
several ECMAScript implementations.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#26500

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-01-08 17:54 +0100
Message-ID<3105476.iMYZV00USQ@PointedEars.de>
In reply to#26496
Christoph M. Becker wrote:

> John Harris wrote:
>> On Wed, 07 Jan 2015 17:22:40 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>> It is because, as is obvious from the above, he has not realized yet
>>> that there are (at least) two ways to “define” a function in ECMAScript,
>>> of which one includes a *declaration*.
>> 
>> Both ways create a function object. One way gives it a global name,
>> the other need not. What else matters?
> 
> Most importantly scope rules.

The scope (chain) rules are the same with either syntax.

> A function declaration creates a function object that is passed in the 
> *variable* environment of the running execution context as environment;
> a function object that is created by a function expression is passed in 
> the *lexical* environment.

Objects are not "passed in environments".

<http://ecma-international.org/ecma-262/5.1/#sec-10.3>

| LexicalEnvironment  | Identifies the Lexical Environment
|                     | used to resolve identifier references made by code
|                     | within this execution context.
| --------------------+---------------------------------------------------
| VariableEnvironment | Identifies the Lexical Environment
|                     | whose environment record holds bindings created by
|                     | VariableStatements and FunctionDeclarations within 
|                     | this execution context.

(intentional word-wrap)

> Informally, one might say that function declarations are "hoisted".

Yes, but as with all informal descriptions, it is imprecise and potentially 
misleading.  For example, a so "hoisted" function can still access 
identifiers in the outer execution context even though they have only been 
defined (and assigned to) later, because it is a closure and because of the 
scope chain:

  var answer;

  function deepThought ()
  {
    return answer;
  }

  /* undefined */
  deepThought();

  answer = 42;

  /* 42 */
  deepThought();

> Another pitfall that one should be aware of is that the behavior of a
> function expression in a statement context is standardized, while the
> behavior of a function declaration (better called function statement
> here) in a statement context is not, even though it is allowed in
> several ECMAScript implementations.

True.  However, I think it is more important to realize that function 
expressions observe source code order (so I referred to that).  A function 
defined with a function expression is not defined before execution *passed* 
the latter.

  /* 42 */
  foo();

  function foo ()
  {
    return 42;
  }

  /* TypeError: undefined is not a function */
  bar();

  var bar = function () {
    return 42;
  };

[Per Specification, this is independent of whether the function *expression* 
contains an identifier (a function *declaration* must contain an identifier 
or it is parsed as a function expression).  There is a JScript bug, fixed in 
version 9+ when in IE 9+ standards Document Mode¹ (test with Firebug Lite or 
F12 – developer tools), that allows the bar() call above to be successful if 
you write

  var bar = function bar () {
    return 42;
  }; 

instead.  IOW, the function identifier can leak to the outer scope.

______
¹ Did I already say that there is no javascript/Javascript?]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#26502

From"Christoph M. Becker" <cmbecker69@arcor.de>
Date2015-01-08 19:48 +0100
Message-ID<m8mjd3$de4$1@solani.org>
In reply to#26500
Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> John Harris wrote:
>>> On Wed, 07 Jan 2015 17:22:40 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>>>> It is because, as is obvious from the above, he has not realized yet
>>>> that there are (at least) two ways to “define” a function in ECMAScript,
>>>> of which one includes a *declaration*.
>>>
>>> Both ways create a function object. One way gives it a global name,
>>> the other need not. What else matters?
>>
>> Most importantly scope rules.
> 
> The scope (chain) rules are the same with either syntax.

ACK.

>> A function declaration creates a function object that is passed in the 
>> *variable* environment of the running execution context as environment;
>> a function object that is created by a function expression is passed in 
>> the *lexical* environment.
> 
> Objects are not "passed in environments".

I had written (simplified): "an object that is passed in something as
environment".  The "in" is superfluous or plain wrong -- I'm not sure.

Thanks for the clarifications. :)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#26505

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-01-08 22:09 +0100
Message-ID<3039223.p41ss7ciAv@PointedEars.de>
In reply to#26502
Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph M. Becker wrote:
>>> A function declaration creates a function object that is passed in the
>>> *variable* environment of the running execution context as environment;
>>> a function object that is created by a function expression is passed in
>>> the *lexical* environment.
>> 
>> Objects are not "passed in environments".
> 
> I had written (simplified): "an object that is passed in something as
> environment".  The "in" is superfluous or plain wrong -- I'm not sure.

If you consult the ECMAScript Language Specification again, you can see that 
this statement is wrong either way:

,-<http://ecma-international.org/ecma-262/5.1/#sec-10.2>
| 
| A Lexical Environment is a specification type used to define the 
| association of /Identifiers/ to specific variables and functions based 
| upon the lexical nesting structure of ECMAScript code.

IOW, Lexical Environments are used for resolving identifiers instead (this 
is not an ECMAScript-specific idea).  Neither are objects "passed in 
something as environment" nor are objects passed in(to) environments; 
certainly Function instances (your “function objects”) are not.

As for function declarations vs. expressions:

<http://ecma-international.org/ecma-262/5.1/#sec-11.2.5>

| Semantics
| 
| The production
| 
| FunctionDeclaration : function Identifier ( FormalParameterList_opt ) { 
| FunctionBody }
| 
| is instantiated as follows during Declaration Binding instantiation 
| (10.5):
| 
| 1. Return the result of creating a new Function object as specified in 
|    [section] 13.2 with parameters specified by FormalParameterList_opt, 
|    and body specified by FunctionBody.
|    Pass in the VariableEnvironment of the running execution context as
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|    the Scope. Pass in true as the Strict flag if the FunctionDeclaration
     ^^^^^^^^^
|    is contained in strict code or if its FunctionBody is strict code.
| 
| 
| The production
| 
| FunctionExpression : function ( FormalParameterList_opt ) { FunctionBody }
| 
| is evaluated as follows:
| 
| 1. Return the result of creating a new Function object as specified in 
|    [section] 13.2 [“Creating Function Objects”; the ed.] with parameters 
|    specified by FormalParameterList_opt and body specified by 
|    FunctionBody.
|    Pass in the LexicalEnvironment of the running execution context
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|    as the Scope.
     ^^^^^^^^^^^^^
|    Pass in true as the Strict flag if the FunctionExpression is contained
|    in strict code or if its FunctionBody is strict code.

The section referred is

<http://ecma-international.org/ecma-262/5.1/#sec-13.2>

| 13.2 Creating Function Objects
| 
| Given an optional parameter list specified by FormalParameterList, a body 
| specified by FunctionBody, a Lexical Environment specified by Scope, and a 
| Boolean flag Strict, a Function object is constructed as follows:
| 
| 1. Create a new native ECMAScript object and let F be that object.
| […]
| 9. Set the [[Scope]] internal property of F to the value of Scope.
| […]

Continuing in section 11.2.5, you can read:

| The production
| 
| FunctionExpression : function Identifier ( FormalParameterListopt ) { 
| FunctionBody }
| 
| is evaluated as follows:
| 
| 1. Let funcEnv be the result of calling NewDeclarativeEnvironment passing 
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|    the running execution context’s Lexical Environment as the argument
                                                         ^^^^^^^^^^^^^^^
The section referred is

<http://ecma-international.org/ecma-262/5.1/#sec-10.2.2.2>

| 10.2.2.2 NewDeclarativeEnvironment (E)
| 
| When the abstract operation NewDeclarativeEnvironment is called with 
| either a Lexical Environment or null as argument E the following steps are 
| performed:
| 
| 1. Let env be a new Lexical Environment.
| 2. Let envRec be a new declarative environment record containing no 
|    bindings.
| 3. Set env’s environment record to be envRec.
| 4. Set the outer lexical environment reference of env to E.
| 5. Return env.

The text above shows that I have been partially wrong: The “scope rules”, as 
you put it, *do* differ between function declarations and function 
expressions; they also differ between function expressions with and without 
identifier.  The subtype, so to speak, of the Function instance’s [[Scope]] 
property’s value is different in both cases, indeed (its type is *always* 
Lexical Environment because by definition both LexicalEnvironment and 
VariableEnvironment are Lexical Environments).

This can be explained as follows:

The identifier of a function created by function declaration needs to be 
available both from inside the function and the (outer) execution context in 
which it was declared.  A Function instance created from a function 
declaration can be accessed and modified from the execution context in which 
it was declared; the function can also modify itself when it is called¹: you 
can assign a value to the identifier of the function to do that, but you 
cannot delete the function, by a “delete” operation on its identifier.  IOW, 
it is treated *like a variable* that is declared in the (outer) execution 
context in which the function was declared.  Also, from the inside 
identifiers in the outer execution context need to be accessible (closure):

  /* result should be "answer" per §12.2, but apparently only available 
     internally */
  var answer = 42;

  function foo (bar)
  {
    /* 1 */
    foo.length;
    
    /* false */
    delete foo;

    /* function foo (bar) { … } */
    foo;

    /* function () { … } */
    foo = function () { return answer; };
  }

  /* undefined */
  foo();

  /* 42 */
  foo();

  foo = function () { return 23; };
  
  /* 23 */
  foo();

[This also allows another function declaration with the same identifier to 
overwrite a previous one in the same execution context.¹]

A function created by function expression without identifier is anonymous; 
without explicit reference, it cannot be referred (or modified) from the 
inside or the outside², but from the inside identifiers in the outer 
execution context need to be accessible (closure):

  /* Script-kiddies, don't do this (at home) */
  var counter = 10;

  (function () {
    if (counter > 0)
    {
      arguments.callee(--counter);
    }
  }());

A function expression with identifier must be treated differently than both 
of those because it must be possible to refer to the resulting Function 
instance by identifier from within the function (for introspection and 
recursion), but not from its defining outer execution context.  Also, it 
must still work as a closure.

  /* see above */
  var answer = 42;

  /* function bar (…) { … } */
  var foo = function bar (baz) {
    /* 1 */
    bar.length;

    /* function () { … } */
    bar = function () { return answer; };
  };

  /* undefined */
  foo();

  /* undefined */
  foo();

  foo = function () { return 23; };
  
  /* overwrites/creates “bar” property, overwrites “bar” variable value,
     or throws “ReferenceError: bar is not defined” in strict mode */
  bar = function () { return 11; };

  /* 23 */
  foo();

______
¹ Loosely speaking.  What really happens is that the identifier then refers
  to a new Function instance, and the old instance is free to be garbage-
  collected unless it is still referred to by something else.  In the case
  of duplicate function declarations in an execution context, an optimizing
  compiler could skip the creation of all Function instances but the last
  one.
² Overwriting arguments.callee might effect that anyway, but that would
  not be conforming behavior (overwriting a property ought not change the
  object referred to by its value).

> Thanks for the clarifications. :)

You're welcome.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#26504

FromJoao Rodrigues <groups_jr-1@yahoo.com.br>
Date2015-01-08 18:22 -0200
Message-ID<m8mouj$ve1$1@speranza.aioe.org>
In reply to#26500
Thomas Lahn wrote:

<snip>

> 
>> Informally, one might say that function declarations are "hoisted".
> 
> Yes, but as with all informal descriptions, it is imprecise and potentially 
> misleading. 

The term "hoisting" can mislead someone who doesn't know that it refers
only to the variable and function declarations, not to the variable
assignment. For example, the code below:

f();
function f() { alert(x); }
var x = 42;

is implicitly executed as:

var x;
function f() { alert(x); }
f();
x = 42;

This behaviour is according to the specification:
<http://ecma-international.org/ecma-262/5.1/#sec-12.2>

>

<snip>

> [...]  A function 
> defined with a function expression is not defined before execution *passed* 
> the latter.

Imprecise terminology.

> 
>   /* 42 */
>   foo();
> 
>   function foo ()
>   {
>     return 42;
>   }
> 
>   /* TypeError: undefined is not a function */
                  ^^^^^^^^^
>   bar();
> 
>   var bar = function () {
>     return 42;
>   };

"TypeError: bar is not a function"


-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#26506

From"Christoph M. Becker" <cmbecker69@arcor.de>
Date2015-01-08 22:13 +0100
Message-ID<m8mrsq$di7$1@solani.org>
In reply to#26504
Joao Rodrigues wrote:

> Thomas Lahn wrote:
> 
>>   /* 42 */
>>   foo();
>>
>>   function foo ()
>>   {
>>     return 42;
>>   }
>>
>>   /* TypeError: undefined is not a function */
>                   ^^^^^^^^^
>>   bar();
>>
>>   var bar = function () {
>>     return 42;
>>   };
> 
> "TypeError: bar is not a function"

The error message depends on the implementation (current Chrome reports
the former, current Firefox the latter, for instance).

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#26507

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2015-01-08 22:25 +0100
Message-ID<16148343.zv1zvVrlGz@PointedEars.de>
In reply to#26504
Joao Rodrigues wrote:

> Thomas Lahn wrote:
> 
> f();
> function f() { alert(x); }
> var x = 42;
> 
> is implicitly executed as:
> 
> var x;
> function f() { alert(x); }
> f();
> x = 42;

  function f () { alert(x); }
  var x;
  f();
  x = 42;

is equally possible.  What matters is that the declarations would have to be 
processed first.

> This behaviour is according to the specification:
> <http://ecma-international.org/ecma-262/5.1/#sec-12.2>

Rather <http://ecma-international.org/ecma-262/5.1/#sec-10.4>.

>> [...]  A function defined with a function expression is not defined 
>> before execution *passed* the latter.
> 
> Imprecise terminology.

In which way?

>> […]
>>   /* TypeError: undefined is not a function */
>                   ^^^^^^^^^
>>   bar();
>> 
>>   var bar = function () {
>>     return 42;
>>   };
> 
> "TypeError: bar is not a function"

The TypeError exception matters.  Error messages that are not
user-defined can and do differ between ECMAScript implementations.

<http://ecma-international.org/ecma-262/5.1/#sec-15.11>

The error message I posted is that of Google V8 JavaScript in Chromium 
“Version 39.0.2171.71 Built on 8.0, running on Debian 8.0 (64-bit)”, in 
which I usually write private test code these days.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#26491

FromJohn Harris <niam@jghnorth.org.uk.invalid>
Date2015-01-08 10:25 +0000
Message-ID<inmsaat0l5h1d0knu7rnbnv27m3lgtppbg@4ax.com>
In reply to#26483
On Wed, 07 Jan 2015 16:41:36 +0100, "Christoph M. Becker"
<cmbecker69@arcor.de> wrote:

>John Harris wrote:
>
>> On Tue, 06 Jan 2015 19:03:33 +0100, "Christoph M. Becker"
>> <cmbecker69@arcor.de> wrote:
>> 
>>> John's argument might be regarded secondary (if not invalid) nowadays.
>> 
>> It's still primary. Seeing where function definitions start and
>> finish, quickly, is vital to maintenance programmers.
>
>ACK.  However, many contemporary editors are able to display vertical
>lines joining the starting and ending line of a "block" ("indentation
>guides"), what is IMO even clearer than aligned braces.  Furthermore
>there is code folding and "jump to matching brace" available even in non
>graphical editors (e.g. vim).

Syntax highlighting isn't available in books, e.g in Crockford's book.
Nor is it available in most news readers, certainly not in the ones
I've used.

  John

[toc] | [prev] | [next] | [standalone]

#26492

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2015-01-08 11:33 +0100
Message-ID<XnsA41C75A65A6EAeejj99@194.109.133.133>
In reply to#26491
John Harris <niam@jghnorth.org.uk.invalid> wrote on 08 jan 2015 in 
comp.lang.javascript:

> Syntax highlighting isn't available in books

True if you mean "printed book", or "spoken book".

> , e.g in Crockford's book.

Don't know about that.

> Nor is it available in most news readers, certainly not in the ones
> I've used.

However, a copy and paste to a dedicated editor is possible,
my newsreader even has the "external editor" option.

That said, I agree with you, that Javascript-code in this NG
preferably should be textual and logical optimized for usenet reading,
meaning on most usenet-conforming readers.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.javascript

csiph-web