thank you for clarifying…
-nag

But as mentioned the syntax of FD is function name(){}. Hope you do agree with me on this.

It mostly not about syntax, but about position in the source code. FEs are always in an expression positions. FDs only at Program level or directly inside another function.

So, a FE can be without parentheses, but still be a FE:

1, function foo() {};
// it's not available (excluding IE's bug)
alert(typeof foo); // "undefined", but not "function"

the output is (function bar(){});, which is not a function declaration syntax as it is being enclosed by parenthesis.

Thus, can i say it is still referring to an expression as the output is enclosed in parenthesis?

Also an IE’s behavior. IE grabs into the string representation of a function (in alert in this case exactly toString method is called, which is may be an implementation dependent) not only parenthesis, but also comments:

// only IE, e.g. IE8
(/* comment */ (((function foo(){}) /* also comment */)));
alert(foo); // (/* comment */ (((function foo(){}) /* also comment */)))

Dmitry.

Under the topic NFE and JScript,

(function bar() {});
var foo = bar;
alert(foo === bar); // true
foo.x = 10;
alert(bar.x); // 10

I do agree the behaviour of IE.
But as mentioned the syntax of FD is function name(){}. Hope you do agree with me on this.

Now in the same example above,

(function bar() {});
alert(bar);

the output is (function bar(){});, which is not a function declaration syntax as it is being enclosed by parenthesis.

Thus, can i say it is still referring to an expression as the output is enclosed in parenthesis?

thanks

-nag

when i execute this script in IE 8 the output is not “undefined” rather the output is the funcion it self. i.e. (function foo(){});. Can you please verify if this is browser/version specific.

Yes, this is IE’s specific behavior, and it’s not a feature, it’s a bug. An identifier (a name) of a function expression should not pollute outside variable object.

Read again carefully section NFE and JScript devoted to JScript’s (IE) bugs. They should be fixed (possibly not all) though in IE9.

Dmitry.

Your effort to disseminate JavaScript concepts is incomparable. I did learn a so much.
In the following context:
“Also in the definition is said that FE is created at the code execution stage and is not stored in the variable object. Let’s see this behavior on the example:

// FE is not available neither before the definition
// (because it is created at code execution phase),
alert(foo); // "foo" is not defined
(function foo() {});
// nor after, because it is not in the VO
alert(foo);  // "foo" is not defined  

when i execute this script in IE 8 the output is not “undefined” rather the output is the funcion it self. i.e. (function foo(){});. Can you please verify if this is browser/version specific.

-nag

Thanks, yeah, it was a typo.

Dmitry.

object.bar = function() { ...

This should be

foo.bar = function() { ...

Thank you for the articles. Very helpful for those (like me) who are too lazy to read the spec.

thanks.

if the onclick is a property of a HTML node object, do you have any idea how do they handle this case of setting the property of HTMLNode object to, in this case two statements?

Do they create a function expression as a wrapper??

Actually, this isn’t a part of ECMAScript and relates already to the implementation of the host environment — in this case to the DOM.

So, to know how exactly some implementation manages this case, we should examines sources of those implementations.

But in general, yep, there is nothing else as creating of the corresponding method (based on attributes value, i.e. source code) for the node object.

For example, in Firefox:

<input type="text" id="el" onclick="alert(event);" />

var el = document.getElementById('el');

// function object is build and bound
// to the el node object
//
// function onclick(even) {
//   alert(event);
// }

alert(el.onclick);

So you see, that Gecko engine creates function with the same name “onclick” and even hardcoded by default parameter name — “event” (in IE it is global property). And the body of this function — is the source code taken from the “onclick” attribute. Therefore, we can use name “event” in that attribute value in FF.

And “onclick” attribute is still string:

var onClickAttr = el.getAttribute("onclick");

// "string", "alert(event);"
alert([typeof onClickAttr, onClickAttr]);

But setting corresponding method doesn’t update in FF “onclick” attribute:

el.onclick = function (e) {
  alert(e);
};

// source code of the
// new funciton
alert(el.onclick);

// get again attribute value after that
onClickAttr = el.getAttribute("onclick");

// still old "alert(event);"
alert(onClickAttr);

And setting the attribute doesn’t update “onclick” method. Meanwhile on real clicking on the element after that new event set via attribute — we see reaction of this new source code evaluated:

el.setAttribute("onclick", "alert(1);");

onClickAttr = el.getAttribute("onclick");

// "alert(1);"
alert(onClickAttr);

// stil old with "alert(e);"
alert(el.onclick);

But that just about FF. I.e. it depends on implementation and it depends twice because it is even not implementation of JS but of the host environment.

In Safari (WebKit) and Chrome (V8) the last alert shows updated via the attribute setting state:

// function onlick(event) {alert(1);}
alert(el.onclick);

IE vice-versa — shows correctly all updates of “onclick” attribute/method, but doesn’t set handler at all if you set it via dynamic attribute setting.

So, the host environment world has own privileges (and can implement such cases in own manner) and also has own bugs.

Dmitry.