Execution context, Identifier resolution, Variable instantiation

A

Asen Bozhilov

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)?
 
R

RobG

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:

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/ >
 
T

Thomas 'PointedEars' Lahn

RobG said:
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
 
G

Garrett Smith

Thomas said:
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.
 
T

Thomas 'PointedEars' Lahn

Garrett said:
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
 
A

Asen Bozhilov

RobG said:
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.
 
L

Lasse Reichstein Nielsen

Asen Bozhilov said:
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'
 
M

Matthias Reuter

Richard said:
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
 
D

Dmitry A. Soshnikov

[...]
"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#Context>

There said:
--- "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.
 
A

Asen Bozhilov

Dmitry said:
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'.
 
G

Garrett Smith

Richard said:
"Pro JavaScript Techniques", or "Secrets of the JavaScript Ninja"? The
first certainly failed to satisfy the "providing correct intelligence
about ... " proposition.


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.
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.
 
T

Thomas 'PointedEars' Lahn

Andrea said:
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
 
A

Andrea Giammarchi

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
 
D

Dmitry A. Soshnikov

[...]
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.
 
A

Andrea Giammarchi

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.
 
D

Dmitry A. Soshnikov

[...]
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.
 
A

Andrea Giammarchi

On Nov 13, 9:43 am, Thomas 'PointedEars' Lahn <[email protected]>
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
 
D

Dmitry A. Soshnikov

[...]
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top