Execution context, Identifier resolution, Variable instantiation

Discussion in 'Javascript' started by Asen Bozhilov, Nov 10, 2009.

  1. Today i read one article in one blog. Article title is:
    "Internet Explorer Scope Resolution"

    | Scope variables are resolved after functions and
    | unless we forget to assign a value,
    | leaving them undefined, these variables will have a privileged
    reference.
    | This means that if we declare var foo = null;
    | exactly at the top of above example scope,
    | the latter one will consider foo a null reference.

    Maybe someone will be say, "your english is bad". Yes my english is
    not very well. But the text above is completely wrong. ECMA 3
    documentation explains each of point here.

    | (function(){
    | alert(foo); // the function!
    | // function foo(){/* 2 */}
    | var foo = null;
    | alert(foo); // null
    | function foo(){/* 1 */};
    |
    | function foo(){/* 2 */};
    | alert(foo); // null
    | })();

    Identifiers for function and variable declaration will be added as
    property of Variable Object on entering in execution context.

    | 10.1.3 Variable Instantiation

    | For each FunctionDeclaration in the code,
    | in source text order, create a property of the variable object
    whose
    | name is the Identifier in the FunctionDeclaration,
    | whose value is the result returned by creating a Function object
    | .....
    | If the variable object
    | already has a property with this name,
    | replace its value and attributes.

    | For each VariableDeclaration or VariableDeclarationNoIn in the code
    | If there is already a property of the variable object with
    | the name of a declared variable,
    | the value of the property and its attributes are not changed.

    | 10.1.4 Scope Chain and Identifier Resolution
    | During execution ...

    | alert(foo); // the function!
    | // function foo(){/* 2 */}

    After quotation from ECMA3 documentation that is absolutely expected
    behaviour. And that:

    (function(){
    window.alert(foo); //reference to `function'
    function foo(){};
    var foo;
    })();

    variable declaration with identifier `foo' can't change attributes and
    value of property with name `foo' of Activation/Variavble Object.

    | var foo = null;
    | alert(foo); // null

    Again expected behaviour. Assignment expression will be executed
    runtime and will be replace value of property `name' with value
    produced from assignment expression.

    | 11.13 Assignment Operators
    | 2. Evaluate AssignmentExpression.
    | 3. Call GetValue(Result(2)).

    Before i read c.l.js i was read many tutorial about JavaScript. All of
    that tutorials doesn't have reference to ECMA262 documentation. When i
    start to read here, i don't understand many things about ECMA262. Now
    again i don't understand many things, but here is only place where i
    get relevant information about ECMA262.
    The man who produced that article have title "javascript ninja". What
    mean that? After a few months i read one article produced from Garrett
    Smith about "javascript magic". At the moment i don't see Garret Smith
    article.

    Why all of that? Why i don't see one good book for ECMA 262
    (JavaScript)?
    Asen Bozhilov, Nov 10, 2009
    #1
    1. Advertising

  2. Asen Bozhilov

    RobG Guest

    On Nov 11, 8:20 am, Asen Bozhilov <> wrote:
    > Today i read one article in one blog. Article title is:
    > "Internet Explorer Scope Resolution"
    >
    > | Scope variables are resolved after functions and
    > | unless we forget to assign a value,
    > | leaving them undefined, these variables will have a privileged
    > reference.
    > | This means that if we declare var foo = null;
    > | exactly at the top of above example scope,


    It would have been good to include the example, or provided a
    reference to it.


    > | the latter one will consider foo a null reference.
    >
    > Maybe someone will be say, "your english is bad". Yes my english is
    > not very well.


    No need to be defensive, your english is OK.

    [...]

    > Before i read c.l.js i was read many tutorial about JavaScript. All of
    > that tutorials doesn't have reference to ECMA262 documentation. When i
    > start to read here, i don't understand many things about ECMA262. Now
    > again i don't understand many things, but here is only place where i
    > get relevant information about ECMA262.


    Yes, there are pleny of "experts" on javascript who have a a poor
    grasp of ECMA-262. They don't tend to post here as if they do, they
    are corrected and so either their understanding improves or they get
    annoyed that they aren't as clever as they thought they were and go
    away.

    If you want a good article on variable instatiation, identifier
    resolution and so on, try this article in the FAQ:

    <URL: http://www.jibbering.com/faq/faq_notes/closures.html >


    > The man who produced that article have title "javascript ninja". What
    > mean that?


    It means he's a cool dude who thinks he knows a lot more than he does.
    Of course, taken literally, a ninja was an assassin or saboteur so I
    guess he thinks he's good a killing or destroying things related to
    javascript. Perhaps not such a cool title after all.


    > After a few months i read one article produced from Garrett
    > Smith about "javascript magic". At the moment i don't see Garret Smith
    > article.
    >
    > Why all of that? Why i don't see one good book for ECMA 262
    > (JavaScript)?


    The videos at YUI Theatre are pretty good, as is Douglas Crockford's
    book "JavaScript: The Good Parts". But the book isn't for beginners,
    it's more his musings on the subject.

    <URL: http://developer.yahoo.com/yui/theater/ >


    --
    Rob
    RobG, Nov 10, 2009
    #2
    1. Advertising

  3. RobG wrote:

    > On Nov 11, 8:20 am, Asen Bozhilov <> wrote:
    >> The man who produced that article have title "javascript ninja". What
    >> mean that?

    >
    > It means he's a cool dude who thinks he knows a lot more than he does.
    > Of course, taken literally, a ninja was an assassin or saboteur so I
    > guess he thinks he's good a killing or destroying things related to
    > javascript. Perhaps not such a cool title after all.


    You do want to review your knowledge about feudal Japan, though. Ninjas had
    various assignments that included, but were not limited to, assassination or
    sabotage. In fact, in the best sense of the word a ninja was a scout, and
    it can be assumed that it is this meaning from which Resig derived his self-
    assigned title (though he fails badly in doing what a scout is supposed to
    do, providing correct intelligence about unknown territory).

    > The videos at YUI Theatre are pretty good,


    Has it not been determined here already that they are not?

    > as is Douglas Crockford's book "JavaScript: The Good Parts". But the book
    > isn't for beginners, it's more his musings on the subject.


    From what I have seen of it here, it is more filled with his opinions about
    how the language should be. Opinions that not necessarily have a rational
    basis (as for those presented here, there was no rationale for the
    recommendations given at all, and there have been rational reasons presented
    why the respective Crockford's recommendation was utter nonsense, indeed).


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Nov 11, 2009
    #3
  4. Thomas 'PointedEars' Lahn wrote:
    > RobG wrote:
    >
    >> On Nov 11, 8:20 am, Asen Bozhilov <> wrote:
    >>> The man who produced that article have title "javascript ninja". What
    >>> mean that?

    >> It means he's a cool dude who thinks he knows a lot more than he does.
    >> Of course, taken literally, a ninja was an assassin or saboteur so I
    >> guess he thinks he's good a killing or destroying things related to
    >> javascript. Perhaps not such a cool title after all.

    >
    > You do want to review your knowledge about feudal Japan, though. Ninjas had
    > various assignments that included, but were not limited to, assassination or
    > sabotage. In fact, in the best sense of the word a ninja was a scout, and
    > it can be assumed that it is this meaning from which Resig derived his self-
    > assigned title (though he fails badly in doing what a scout is supposed to
    > do, providing correct intelligence about unknown territory).
    >


    Did you already read the book? It is not even published yet, is it?

    The term "javascript ninja" is sometimes used tounge-in-cheek among
    those who do not understand or think front end engineering work as not
    real programming.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Nov 11, 2009
    #4
  5. Garrett Smith wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> RobG wrote:
    >>> On Nov 11, 8:20 am, Asen Bozhilov <> wrote:
    >>>> The man who produced that article have title "javascript ninja". What
    >>>> mean that?
    >>> It means he's a cool dude who thinks he knows a lot more than he does.
    >>> Of course, taken literally, a ninja was an assassin or saboteur so I
    >>> guess he thinks he's good a killing or destroying things related to
    >>> javascript. Perhaps not such a cool title after all.

    >>
    >> You do want to review your knowledge about feudal Japan, though. Ninjas
    >> had various assignments that included, but were not limited to,
    >> assassination or
    >> sabotage. In fact, in the best sense of the word a ninja was a scout,
    >> and it can be assumed that it is this meaning from which Resig derived
    >> his self- assigned title (though he fails badly in doing what a scout is
    >> supposed to do, providing correct intelligence about unknown territory).

    >
    > Did you already read the book?


    Are you serious? Of course not, and I am not going to. I will wait for
    Resig's daydreams to hit ground here instead.

    > It is not even published yet, is it?


    Relevance? I wrote "assumed".

    > The term "javascript ninja" is sometimes used tounge-in-cheek among
    > those who do not understand or think front end engineering work as not
    > real programming.


    Parse error.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Nov 11, 2009
    #5
  6. RobG wrote:

    > If you want a good article on variable instatiation, identifier
    > resolution and so on, try this article in the FAQ:
    >
    > <URL:http://www.jibbering.com/faq/faq_notes/closures.html>


    Of course, that article is very good and i have this article in my
    bookmarks. Article explain how it works "closure", referred to ECMA262
    3 documentation and it was writing from man who deep understand
    ECMA262 and JavaScript.

    | * Written by Richard Cornford. March 2004.
    | * With corrections and suggestions by:-
    | o Martin Honnen.
    | o Yann-Erwan Perio (Yep).
    | o Lasse Reichstein Nielsen. (definition of closure)
    | o Mike Scirocco.
    | o Dr John Stockton.

    Each of these men, have academical knowledge in ECMA262 and other
    things in common between them is, each of these is member of c.l.js.

    > The videos at YUI Theatre are pretty good, as is Douglas Crockford's
    > book "JavaScript: The Good Parts". But the book isn't for beginners,
    > it's more his musings on the subject.
    >
    > <URL:http://developer.yahoo.com/yui/theater/>


    Yes but YUI Theatre serve code and terminology. They don't explain how
    it works things and what exactly means terms which been using in they
    videos. I want to know. Why this approach is better from others? I
    want to know how it works? I'm not keyboard monkey who want everything
    finished, and i don't want to use code who i don't know how it works.
    Asen Bozhilov, Nov 11, 2009
    #6
  7. Re: Execution context, Identifier resolution, Variableinstantiation

    Asen Bozhilov <> writes:

    > Today i read one article in one blog. Article title is:
    > "Internet Explorer Scope Resolution"
    >
    > | Scope variables are resolved after functions and
    > | unless we forget to assign a value,
    > | leaving them undefined, these variables will have a privileged reference.
    > | This means that if we declare var foo = null;
    > | exactly at the top of above example scope,
    > | the latter one will consider foo a null reference.


    It might make more sense in-context, but I have no idea what
    "privileged reference" means here. Which makes the entire paragraph
    rather uninformative.

    Ok, I looked at the "HTML slides". The point where IE diverges from
    the standard is only that function expressions with a name also
    function as function declarations. Other than that, the remaining
    behavior is exactly as expected for a scope with variable and function
    declarations with the same name. The wording of the explanation seems
    like Voodoo Science explanation for a perfectly normal behavior.

    I.e., you are correct, with the added provision that IE treates
    something as function declarations that really should be function
    literals.

    /L 'JavaScript Voodoo Priest'
    --
    Lasse Reichstein Holst Nielsen
    'Javascript frameworks is a disruptive technology'
    Lasse Reichstein Nielsen, Nov 11, 2009
    #7
  8. Richard Cornford wrote:

    > I always found "Guru" and odd label for people to want to attach to
    > themselves or others (eastern mysticism being virtually synonymous with
    > fakery).


    Frontendguru was the label attached to me by the backend developers in my
    team. Product Management calls us Script Botchers. I can't help it, but
    somehow guru sounds better to me.

    Matt
    Matthias Reuter, Nov 12, 2009
    #8
  9. On Nov 11, 5:18 pm, "Richard Cornford" <>
    wrote:

    > [...]
    > "Secrets of the JavaScript Ninja"?
    > [...]


    We also discussed some parts of this book on Russian forum <URL:
    http://javascript.ru/forum/misc/5724-secrets-javascript-ninja.html>.

    > [...]
    > <URL:http://jsninja.com/Functions#Function_Type>
    > [...]


    <URL: http://jsninja.com/Functions#Context>

    There Resig writes:

    > --- "To start, it's important to realize what that the function context represents: The object within which the function is being executed. For example, *defining* a function within an object structure *will ensure that itscontext always refers to that object* - unless otherwise overwritten... However, what about a *function that isn't explicitly *declared* as a property of an object*? Then the function's context refers to the *global object*." <


    Typical newbie-mistakes. Even if Resig knows himself that this is
    wrong - that's really disinformation for the readers. If he would
    talking about calling the function, but not the *definition*, maybe
    this words would make sense (except sure that he uses term *context*
    not in meaning of context in ECMA (execution context), but means [this-
    value]. But, in case of *calling* function term context is allowed).

    About - "*function that isn't explicitly *declared* as a property of
    an object*? Then the function's context refers to the *global object*"
    - also wrong info for newbies. Even "simple" function can be called
    with different variants of [this-value], without apply/call, like:

    // declaration, Resig says
    // [this-value] will be global

    function foo() {}

    foo(); // this - global
    foo.prototype.constructor(); // this - foo.prototype

    Also in chapter of prototypes there're some wrong descriptions. But I
    didn't read this book fully, just saw some chapters a bit.

    What i think about: Resig works in Mozilla, right? Why didn't he ask
    and advise of e.g. B.Eich for clarify some moments of ES? Why did he
    call himself "JavaScript Evangelist" if he writes with such mistakes?

    So Resig's literature for now sure is not academical, but contains
    many mistakes, misunderstanding, self-called, self-named things which
    he didn't understand.

    But, there's other side of the coin (which I can suggest) - Resig
    knows all of that stuff, but just writes in easy manner for to get
    more people interested - with funny pictures, simplify naming of
    ECMA-262 terms and so on. But if it is so, why did this stuff is
    called "Ninjas stuff"? Which means - "in book contains professional
    information of ES". It's just PR.
    Dmitry A. Soshnikov, Nov 12, 2009
    #9
  10. Dmitry A. Soshnikov wrote:

    > But, there's other side of the coin (which I can suggest) - Resig
    > knows all of that stuff, but just writes in easy manner for to get
    > more people interested - with funny pictures, simplify naming of
    > ECMA-262 terms and so on. But if it is so, why did this stuff is
    > called "Ninjas stuff"? Which means - "in book contains professional
    > information of ES". It's just PR.


    Easy manner is totally different from error explanations. If you good
    know something, you can give easy to understood explanations about it.
    Programming at all is not easy job, and when i want book for
    professional that mean i want book for professional, if i want book to
    "Script kids" i will be searching book for "Script kids".

    What about this:

    | Temporary Scope and Private Variables

    | Using the executed anonymous function we can start to build up
    interesting enclosures for our work.
    | Since the function is executed immediately, and all the variables
    inside of it are kept inside of it,
    | we can use this to create a temporary scope within which our state
    can be maintained, like in the following example:


    | (function(){
    | var numClicks = 0;
    |
    | document.addEventListener("click", function(){
    | alert( ++numClicks );
    | }, false);
    | })();

    What is temporary? Richard Cornford article complete explain behaviour
    like this.
    <URL: http://www.jibbering.com/faq/faq_notes/closures.html >
    If anybody read it and read ECMA262 documentation will be know. Here
    doesn't have "temporary scope".

    | Richard Cornford wrote:
    | [[scope]] property referring to a scope chain containing the
    Activation/Variable object
    | belonging to the execution context in which it was created (and the
    global object).
    | Now the Activation/Variable object cannot be garbage collected
    either as the execution of the function object referred to by
    globalVar
    | will need to add the whole scope chain from its [[scope]] property
    to the scope of the execution context created for each call to it.

    That will be happen with anonymous function expression passed to
    `addEventListener'.
    Asen Bozhilov, Nov 12, 2009
    #10
  11. Richard Cornford wrote:
    > Garrett Smith wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> RobG wrote:
    >>>> On Nov 11, 8:20 am, Asen Bozhilov wrote:
    >>>>> The man who produced that article have title "javascript ninja".
    >>>>> What mean that?
    >>>> It means he's a cool dude who thinks he knows a lot more than he
    >>>> does. Of course, taken literally, a ninja was an assassin or
    >>>> saboteur so I guess he thinks he's good a killing or destroying
    >>>> things related to javascript. Perhaps not such a cool title after
    >>>> all.
    >>>
    >>> You do want to review your knowledge about feudal Japan, though.
    >>> Ninjas had various assignments that included, but were not limited
    >>> to, assassination or sabotage. In fact, in the best sense of the
    >>> word a ninja was a scout, and it can be assumed that it is this
    >>> meaning from which Resig derived his self-assigned title (though
    >>> he fails badly in doing what a scout is supposed to do, providing
    >>> correct intelligence about unknown territory).
    >>>

    >>
    >> Did you already read the book?

    >
    > "Pro JavaScript Techniques", or "Secrets of the JavaScript Ninja"? The
    > first certainly failed to satisfy the "providing correct intelligence
    > about ... " proposition.
    >
    >> It is not even published yet, is it?

    >
    > Material purporting to be draft text for "Secrets of the JavaScript
    > Ninja" is available, e.g.:-
    >


    I see now.

    [snip]

    That is worse than I anticipated.

    I see a page on cross browser scripting providing advice on how to
    use hasOwnProperty to filter loops. (Just don't modify Object.prototype)

    I see an example of "Order of Stylesheets: "
    | The best way to ensure that CSS rules (provided by stylesheets) are
    | available when the JavaScript code on the page executes is to
    | specifying the external stylesheets prior to including the external
    | script files.

    Load order may vary and is not standardized. I am pretty sure that the
    technique espoused fails in at least a few browsers where the element
    may be available, yet the script is run, but all of the stylesheet
    information is not yet available.

    I see an example that creates javascript errors in IE:

    | <script>
    | // Perform the initial attribute check
    | var STYLE_NAME = (function(){
    | var div = document.createElement("div");
    | div.style.color = "red";
    |
    | if ( div.getAttribute("style") )
    | return "style";
    |
    | if ( div.getAttribute("cssText") )
    | return "cssText";
    | })();
    |
    | // Later on:
    | window.onload = function(){
    | document.getElementsById("test2").getAttribute( STYLE_NAME ) =
    | document.getElementById("test").getAttribute( STYLE_NAME );
    | };
    | </script>
    |
    | In this example we, again, break down into two parts. We start by
    | creating a dummy element, setting a style property, and then attempt
    | to get the complete style information back out again. We start by
    | using the standards-compliant way (accessing the style attribute) then
    | by trying the Internet Explorer-specific way. In either case we return
    | the name of the property that worked.
    |
    | We can then use that property name at any point in our code when it
    | comes time to get or set style attribute values, which is what we do
    | when the page fully loads.

    The code creates an error in IE, but oddly was intented to avoid an
    error in IE. It just misses the point and creates a bug instead.

    To avoid the problem, the program could just not use getAttribute and
    instead access ElementCSSInlineStyle ".style". That property has
    a string cssText property.

    I won't be reading any more of that.

    The FAQ needs work. I'd rather focus my (limited) time and energy on
    that.

    Update coming soon.

    >
    >> The term "javascript ninja" is sometimes used tounge-in-cheek
    >> among those who do not understand or think front end engineering
    >> work as not real programming.

    >
    > So that would be a usage stressing the 'hired' and/or 'disposable'
    > aspects of "ninja"?
    >


    For those on the back end, front end work is a menial and painful task.

    > I always found "Guru" and odd label for people to want to attach to
    > themselves or others (eastern mysticism being virtually synonymous with
    > fakery).
    >

    Yep. Same deal.

    Interviews for front end engineering are hard on both ends (interviewer
    and interviewee). There amount of public misinformation puts a burden on
    the interviewer of what to ask, who to trust, etc.

    The wrong questions are inevitable. Questions such as: "What is your
    favorite library" (popular) seem like a waste of time.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Nov 13, 2009
    #11
  12. Andrea Giammarchi wrote:

    > alert(a);
    > if(true){
    > function a(){/*1*/};
    > } else {
    > function a(){/*2*/};
    > };
    >
    > Where in Internet Explorer that code will produce this alert:
    > function a(){/*2*/};


    A counter-intuitive result, produced by JScript (not IE) adhering to the
    ECMAScript Specifications with regard to function declarations, but not with
    regard to /Block/ statements. (AFAICS, ES5 is not going to change that.)

    > READ CAREFULLY, the second named function declaration that should not
    > even considered by the parser being the first condition always true.
    >
    > This behavior has been described by kangax first
    > http://yura.thinkweb2.com/named-function-expressions/
    > and me in that post to provide a solution for Internet Explorer,
    > explaining why there is a problem, and how to solve it.
    >
    > Bear in mind the solution is to avoid usage of arguments.callee


    No, apparently you misunderstood. If a recursive function (that is, a
    function that directly calls itself) is to be defined, `arguments.callee'
    can become necessary in order to avoid the aforementioned JScript (not IE)
    peculiarity as

    function a()
    {
    return 42;
    }

    if (true)
    {
    var f = function a() { return 23; };
    }
    else
    {
    f = function a() { return 666; };
    };

    /* should return `42', but returns `666' in JScript */
    a();

    where standards-compliant use of /FunctionExpression/s is involved, current
    JScript implementations parse it as if it were a /FunctionDeclaration/,
    creating a property named `a' on a Variable Object -- or (here) replacing
    the previous value of `a' -- during variable instantiation, when it should
    not. The apparently counter-intuitive results which this peculiarity can
    produce suggest that this behavior was not intended by the implementor,
    which suffices for calling it a JScript bug instead.

    The *workaround* for it is using an anonymous function expression instead --

    function a()
    {
    return 42;
    }

    if (true)
    {
    var f = function(){/*1*/};
    }
    else
    {
    f = function(){/*2*/};
    };

    -- by which it becomes necessary, if the function referred to by `f' should
    be recursive, to use either `f' or `arguments.callee' within the function.

    If `f' is unavailable, or one wants to avoid referring to `f' from within
    the function (as in avoiding closures), `arguments.callee' is left as the
    only option not to trigger the JScript bug. It can become necessary to do
    that as JScript is currently probably the most widely implemented script
    engine today (due to the ongoing market dominance of Microsoft Windows and
    MSHTML), and in particular MSHTML/JScript is known for memory leaks with
    circular references that involve host objects.

    > since in ES5 and "use strict";


    Non sequitur. To begin with, it remains to be seen when and if ES5 (after
    when and if it has been accepted by Ecma International, and perhaps ISO/IEC
    later) will be sufficiently implemented by relevant runtime environments.

    > it won't be there.


    Would you pass me that working crystal ball of yours, please?

    > Moreover, that example IS NOT STANDARD, so whatever specs you read,
    > you did not read them properly,


    Hear, hear!

    > cause the behavior of multiple named function declaration


    The term "named function declaration" suggests that there was an "anonymous
    function declaration", where in fact there is not. Have you understood the
    difference between declarations and expressions?

    > is not well defined,


    But it is, in ES3F, section 10.1.3, Variable Instantiation:

    | For each /FunctionDeclaration/ in the code, in source text order, create a
    | property of the variable object whose name is the /Identifier/ in the
    | /FunctionDeclaration/, whose value is the result returned by creating a
    | Function object as described in section 13, and whose attributes are
    | determined by the type of code. If the variable object already has a
    | property with this name, replace its value and attributes. Semantically,
    | this step must follow the creation of /FormalParameterList/ properties.

    And for the sake of completeness:

    | 13 Function Definition
    |
    | Syntax
    |
    | FunctionDeclaration :
    | function Identifier ( FormalParameterList_opt ) { FunctionBody }
    |
    | [...]

    What is not defined is the meaning of a sequence of tokens that satisfies
    the /FunctionDeclaration/ production, within a /Block/ statement:

    | 12 Statements
    |
    | Syntax
    |
    | Statement :
    | Block
    | VariableStatement
    | EmptyStatement
    | ExpressionStatement
    | IfStatement
    | IterationStatement
    | ContinueStatement
    | BreakStatement
    | ReturnStatement
    | WithStatement
    | LabelledStatement
    | SwitchStatement
    | ThrowStatement
    | TryStatement
    |
    | [...]
    | 12.1 Block
    |
    | Syntax
    |
    | Block :
    | { StatementList_opt }
    |
    | StatementList :
    | Statement
    | StatementList Statement

    And for the sake of completeness:

    | 12.5 The if Statement
    |
    | Syntax
    |
    | IfStatement :
    | if ( Expression ) Statement else Statement
    | if ( Expression ) Statement

    Observe that there is no production to produce /FunctionDeclaration/ for the
    goal symbol /Statement/.

    > in Juryi article as well.


    I have not read it (yet?). Either you or Juryi must have misunderstood
    something.

    > RTFM ... but read it properly.


    Pot, kettle, black.


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Nov 13, 2009
    #12
  13. On Nov 10, 11:20 pm, Asen Bozhilov <> wrote:
    > Today i read one article in one blog. Article title is:
    > "Internet Explorer Scope Resolution"


    and you did not get anything about the article. What I have explained
    step by step is a behavior present only in IE.
    Everything you said, everything you commented, and the way you did, is
    arrogant and just a "blame for free" for whatever reason.

    The example showed in my post
    http://webreflection.blogspot.com/2009/10/internet-explorer-scope-resolution.html
    is THIS:

    alert(a);
    if(true){
    function a(){/*1*/};
    } else {
    function a(){/*2*/};
    };

    Where in Internet Explorer that code will produce this alert:
    function a(){/*2*/};

    READ CAREFULLY, the second named function declaration that should not
    even considered by the parser being the first condition always true.

    This behavior has been described by kangax first
    http://yura.thinkweb2.com/named-function-expressions/
    and me in that post to provide a solution for Internet Explorer,
    explaining why there is a problem, and how to solve it.

    Bear in mind the solution is to avoid usage of arguments.callee since
    in ES5 and "use strict"; it won't be there.

    Moreover, that example IS NOT STANDARD, so whatever specs you read,
    you did not read them properly, cause the behavior of multiple named
    function declaration is not well defined, in Juryi article as well.

    RTFM ... but read it properly.

    This group is hilarious for all the support everybody gives to each
    other blaming for free, without understanding who, what, and where,
    and commenting something nobody ever wrote or said, bulling your self.

    But I am always up for a code challenge whoever you are, so "good
    stuff" ....

    I always love wannabe convinced they can let me delete a post (read
    comments too):
    http://webreflection.blogspot.com/2009/10/internet-explorer-scope-resolution.html

    Best Regards
    Andrea Giammarchi, Nov 13, 2009
    #13
  14. On Nov 13, 11:04 am, Andrea Giammarchi <>
    wrote:
    >
    > [...]
    > This behavior has been described by kangax first
    > http://yura.thinkweb2.com/named-function-expressions/
    > [...]


    kangax's article is good analyze and good article, but IE's bugs with
    NFEs and defining functions in blocks are well known ago, before that.
    Or I didn't understand correctly that kangax wrote it *first*?

    Moreover, IE has the same bug as NFE with e.g. catch clause statement
    when identifier which should a property of an [__catchObject] added in
    front of scope chain.

    alert(e); // ah?
    try {} catch (e) {}
    alert(e) // still alive?

    But in general, you also have a good analyze of IE's bugs in that
    article.

    And about what Asen Bazhilov wrote, there could be just terminological
    and technical cavils:

    | Scope variables are resolved after functions

    Semantically, the step of parsing variables on entering execution
    context (add adding them as properties of AO/VO with values
    [undefined]) should follow the creation of the [FormalParameterList]
    and [FunctionDeclaration] properties.

    | and unless we forget to assign a value,
    | leaving them undefined, these variables will have a privileged
    reference.

    The term "privileged reference" is self-called and is not related to
    ECMA (that's first). And the second is: assignment of the value is
    made already on step of *evaluation* the code of context (that's
    "runtime" of context).

    | This means that if we declare var foo = null;
    | exactly at the top of above example scope,
    | the latter one will consider foo a null reference.

    That's true, but it doesn't related to that and not the reason you
    said - "variables are resolved after functions". All the FD where
    parsed, all the variables where parsed without any assignments of
    values, and only then, when this stage is finished, evaluation stage
    starts and assigns (modifies from [undefined] to) the new value. No
    any FD are parsed (or whatever) on this stage. So sure, the only
    modification in your code is assigning [null] to (VO/AO).foo property.
    Dmitry A. Soshnikov, Nov 13, 2009
    #14

  15. > I have not read it (yet?).  Either you or Juryi must have misunderstood
    > something.


    I did not read your post neither, and you did not read mine. If we
    talk without knowing what my favorite WebReflection troll was talking
    about all this stuff become boring and useless, at least for me, since
    there is nothing for this subject you can teach me as nothing I can
    teach you.

    The blamed post says exactly all you have said here ... EXACTLY the
    same. You can "show off" whatever knowledge you want but you don't
    realize you are underlying what I've wrote already, bringing no news
    in the subject.

    when I say IE, JScript is implicit, I would have said IE with Chrome
    Frame otherwise, but thank you to enlighten me writing (not IE) ...
    you have time, don't you?

    // READ CAREFULLY
    if(true)
    var b = function a(){alert("am I first a? " + a)};
    else
    var c = function a(){alert("am I second a? " + a)};

    If we talk about standards, the one the initial wannabe brought here
    without understanding my post, above example is a named function
    expression assigned to a variable.
    Forget the alert before the expression, and perform this call via IE
    (JScript then ...)

    b();

    above call will produce this alert:
    am I first a? function a(){alert("am I second a? " + a)}
    Note the function body, do you think standards are respected here?
    Write down the exact point that describes above ambiguity please, you
    or mr wannabe at the top, ok?

    What both Juryi article and my IE (yeah, JScript!) Scope Resolution
    post is about how to handle this case.
    We all would like to deal with named expressions for debug purpose and
    we all need to deal with timers as well so we tried to provide a
    universally valid solution, and I did the mistake to explain what is
    going on in IE (of course JScript) without considering the "blame for
    free and as much as possible" new Web Fashion

    JScript does NOT respect standards and only the fact after 3 long post
    in WebReflection plus the blamed one which is just a summary of
    precedent 3 long posts which aim is to describe for gurus and not
    what's up and why in a quick graphical way, THERE IS NOTHING OBVIOUS
    OR EXPECTED, as the blamer said.

    I don't really have time for the copy and paste from the manual
    competition here, all I want to say is that if this ML behaves like
    this where everybody blow out sentences without even investigating
    what the blame is for and what we are talking about, this ML loose
    completely its purpose.

    The fact somebody here is able to write in this ML or follow it, does
    NOT mean anyhow that this somebody is more skilled than anybody else.

    Best Regards.
    Andrea Giammarchi, Nov 13, 2009
    #15
  16. On Nov 13, 9:43 am, Thomas 'PointedEars' Lahn <>
    wrote:

    > [...]
    > What is not defined is the meaning of a sequence of tokens that satisfies
    > the /FunctionDeclaration/ production, within a /Block/ statement:
    > [...]


    > Either you or Juryi must have misunderstood
    > something.
    > [...]


    Juryi's article is quite good, and your need to read carefully chapter
    "16. Errors" of ECMA-262-3. "An implementation may extend program and
    regular expression syntax".

    And one of such extensions is defining function in FD-style in blocks.
    The only possible variant to appear expression in block is
    [ExpressionStatement] which can't start from open bracket and
    [function] keyword. So, by standard such syntax constructions are
    errors. But no one of implementations throws an syntax-error exception
    in this case. All of them are handled this such definition. And the
    Gecko's implementation - is the most logical.

    From one side it doesn't treat such functions as declarations (which
    means they won't be created on entering the context), but from the
    other hand - it also doesn't treat this functions as expressions,
    because e.g. it's not possible to call them with call expression right
    after definition without transforming to FE (in simplest case -
    putting into the grouping operator).

    > /* should return `42', but returns `666' in JScript */
    > a();


    You should also know that JScript creates in this case two different
    objects - [a] and [f]. Always check it out first.
    Dmitry A. Soshnikov, Nov 13, 2009
    #16
  17. On Nov 13, 1:05 pm, Andrea Giammarchi <>
    wrote:

    > [...]
    > What both Juryi article and my
    > [...]


    As variant, I can suggest also this article: <URL:
    http://javascript.ru/blog/Dmitry-A.-Soshnikov/Tonkosti-ECMA-262-3.-CHast-5.-Funkcii.>
    (the only thing and issue for now - the translator from Russian is
    needed); there kangax also gave additions for my articles about
    functions, as I gave for his article.
    Dmitry A. Soshnikov, Nov 13, 2009
    #17
  18. On Nov 13, 10:30 am, "Dmitry A. Soshnikov"
    <> wrote:
    > On Nov 13, 9:43 am, Thomas 'PointedEars' Lahn <>
    > wrote:


    > Juryi's article is quite good


    and its suggestion is nothing different than my example and we all had
    to describes these different not standards behaviors to find out a
    good and cross browser solution.

    The only difference is that Juryi decided to use another name and
    nullify the scope reference at the end.
    This cases names pollution in the scope, plus it requires to remember
    each time what to nullify and inside the function f(){} the reference
    will be F, quite inconsistent but still, what Juryi described is the
    problem, and he provided a solution a have already commented more than
    once in WebReflection.

    The blamed post shows a cross browser solution with consistent named
    referenced, no need to nullify, and no noise for gzip/deflate or,
    theoretically, minifiers.

    Now please somebody brave enough to tell me this argument is obvious,
    expected, and my solution is wrong ... I think we should simply be
    more constructive, avoiding these kind of nonsense blames ... I mean,
    16 replies to a troll which life aim is to blame me and my blog? I was
    expecting a bit more professionalism here but I am sure it is not
    always like this.

    Regards
    Andrea Giammarchi, Nov 13, 2009
    #18
  19. On Nov 13, 3:01 pm, Andrea Giammarchi <>
    wrote:

    > [...]
    > Now please somebody brave enough to tell me this argument is obvious,
    > expected, and my solution is wrong ...


    Nobody says that your solution is wrong. I think Bazhilov wanted just
    to clarify this according to ECMA-262-3 spec. So, don't be worry about
    that. Everything's ok.

    > [...]
    > I think we should simply be
    > more constructive, avoiding these kind of nonsense blames ...


    Right, sure. I always believe and think that the main goal of
    professional discussion - is to find the truth, but not the wish to
    win the dispute, showing what a "Ninja" you are, or sort of (saying
    "No.", "You are wrong" and so on). So, I'm just talking with you
    without any blame.

    Meanwhile, some addition there is. In your code:

    var foo = (function(){
    var foo;
    if(true) {
    foo = function foo(){/* 1 */};
    } else {
    foo = function foo(){/* 2 */};
    };
    return foo;
    })();

    It's not necessary to use enclosing context with anonymous function,
    because you use the same name - [foo]. It could be just like this:

    var foo;

    if (true) {
    foo = function foo(){/* 1 */};
    } else {
    foo = function foo(){/* 2 */};
    };

    foo(); // 1

    Sure on the [foo] will be available before [var foo] as a function
    returning 2, but as you've decided to use exactly FE (even if JScript
    treats them as FD and creates on entering the execution context), that
    means you won't use them above before.

    After that, in runtime of context, the value of property [foo] of AO/
    VO will be changed to new function depending on if-statement. Note,
    that [var foo] even won't be created at all, as function with the same
    name already was in VO/AO when [var foo] was trying to declare.
    Dmitry A. Soshnikov, Nov 13, 2009
    #19
  20. Asen Bozhilov

    Jorge Guest

    On Nov 13, 9:04 am, Andrea Giammarchi <>
    wrote:
    > (...)
    > The example showed in my posthttp://webreflection.blogspot.com/2009/10/internet-explorer-scope-res...
    > is THIS:
    >
    > alert(a);
    > if(true){
    >     function a(){/*1*/};} else {
    >
    >     function a(){/*2*/};
    >
    > };
    >
    > Where in Internet Explorer that code will produce this alert:
    > function a(){/*2*/};


    See Cornfrod's reply here:
    http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/c19e1428f1e1990b

    HTH,
    --
    Jorge.
    Jorge, Nov 13, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page