FAQ Topic - What is (function(){ /*...*/ })() ? (2011-02-12)

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - What is (function(){ /*...*/ })() ?
-----------------------------------------------------------------------

This is an anonymous FunctionExpression that is called
immediately after creation.

Variables declared inside a function are not accessible from
outside the function. This can be useful, for example, to hide
implementation details or to avoid polluting the global scope.

<URL: http://yura.thinkweb2.com/named-function-expressions/>
<URL: http://jibbering.com/faq/notes/closures/>
<URL: http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#question-about-surrounding-parentheses>


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

 

[Thomas 'PointedEars' Lahn]

This is incorrect. Not the FunctionExpression is called, but the function
(Function instance) created by evaluating the FunctionExpression.

Anyhow, the answer is not suitable for a FAQ. We need to be more factual,
less technical there. Who has never read the ECMAScript Specification does
not know the term FunctionExpression and is likely to be confused. The
wording stems from the misconception (that can be seen throughout the FAQ
and FAQ Notes) that a FAQ is written for the people who already know.

"It is an expression that creates an anonymous function, which is called …"

Variables declared inside a function are not accessible from
outside the function. This can be useful, for example, to hide
implementation details or to avoid polluting the global scope.

<URL: http://yura.thinkweb2.com/named-function-expressions/>
<URL: http://jibbering.com/faq/notes/closures/>
<URL:
http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#question-about-

surrounding-parentheses>

AISB: The use of `<URL: http://…>' here is misguided and should be replaced.

RFC 1738 (1994 CE) suggested to use <URL:http://…> (no space in-between).
RFC 2396 (1998), which updated it, already stated that this form was "not
common in practice". RFC 3986 (2005), which obsoletes that, deprecates this
form by saying "The prefix "URL:" (with or without a trailing space)… is not
commonly used in practice and is no longer recommended." That was six years
ago, and this is the most recent RFC on "Uniform Resource Identifier (URI):
Generic Syntax".

RFC 3986 and its predecessor recommend to use <http://…> instead, with which
most software can deal better than with <URL:…>.


PointedEars

 

[John G Harris]

"It is an expression that creates an anonymous function, which is called …"

<snip>

Actually, it creates a function object, as any beginner ought to be
told.

John

 

[Dmitry A. Soshnikov]

This is incorrect. Not the FunctionExpression is called, but the function
(Function instance) created by evaluating the FunctionExpression.

Anyhow, the answer is not suitable for a FAQ. We need to be more factual,
less technical there. Who has never read the ECMAScript Specification does
not know the term FunctionExpression and is likely to be confused.

I always told before that using BNF non-terminals in docs and
discussions is only for spec implementers (or for those who discuss
exactly specs semantics). In casual explanations this BNF can look ugly
(that's the difference of a good written article from the spec copy-paste).

So yeah, I also think this `FunctionExpression` is too technical (which
equals here "too ugly") for the FAQ explanation.

At least, "Function Expression" or even "function expression". Also the
correct naming from the common theory -- "functional expression" can be
used.

Or even more simply and just "it's an anonymous function".

Current more appropriate naming for this which I like most is
"immediately invoked function(al) expression" -- abbr, IIFE.

Another my definition, "Called in-place FE", which means, the function
is created and called directly right in place (though, this definition I
used rarely).

Dmitry.

 

[Thomas 'PointedEars' Lahn]

<snip>

Actually, it creates a function object,

No, it creates a _Function instance_ (which is an object), if you pay
attention.

as any beginner ought to be told.

But not there as it is missing the point. That a function can be called is
common knowledge; that Function instances have a built-in internal [[Call]]
method is not.


PointedEars

 

[John G Harris]

No, it creates a _Function instance_ (which is an object), if you pay
attention.

So you admit you were wrong. You should be more careful when proposing
changes to the text of the FAQ.

Note that the expression defines the function; its evaluation causes a
function object to be created.

as any beginner ought to be told.

But not there as it is missing the point. That a function can be called is
common knowledge; that Function instances have a built-in internal [[Call]]
method is not.

Beginners need to be reminded, in one word, so that they will be able to
understand that
a.f = function ...
assigns an object to a.f.


And have you really stopped believing that "every object is an
`instance'", and hence 'instance' is pointless ?


John

 

[David Mark]

John G Harris wrote:

No, it creates a _Function instance_ (which is an object), if you pay
attention.

So you admit you were wrong. You should be more careful when proposing
changes to the text of the FAQ.

Note that the expression defines the function; its evaluation causes a
function object to be created.

But not there as it is missing the point.  That a function can be called is
common knowledge; that Function instances have a built-in internal [[Call]]
method is not.

Beginners need to be reminded, in one word, so that they will be able to
understand that
   a.f = function ...
assigns an object to a.f.

And have you really stopped believing that "every object is an
`instance'", and hence 'instance' is pointless ?

I agree. Same for "class", "singleton", etc. Using these terms to
describe JS only serves to confuse beginners (particularly those
experienced with other OO languages).

There should be a FAQ topic that explains these terms and why they are
inappropriate for JS discussions.

And the "instanceof" operator has an unfortunate name, which leads to
a lot of questions about its non-relationship with the "constructor"
property. There should be a topic about that as well (assuming there
isn't one already).

 

[Lasse Reichstein Nielsen]

No, it creates a _Function instance_ (which is an object), if you pay
attention.

The specification uses both "function object" (e.g., 13.2 "Creating
Function Objects" and 15.3 "Function Objects") and "function instance"
(15.3.5 "Properties of Function Instances"). The former seems to be the
one most used, with "function instances" only used in section 15.3.5.

I.e., you are both correct (except ofcourse the part where you say
that John G. Harris is wrong), but "function object" would be both the
more natural wording, and the one closest to the way the specification
is written.

I think most beginners would be best served by using "function object".
It's a function, and it's an object, and it's what the specification uses
in most of the text, and it precisely the wording used to describe
*creating* such a value.

So, (function () { }) is an expression that, when evaluated, creates a
function object. And (function() { })() is an expression that creates
a function object and immediately calls it.

But not there as it is missing the point. That a function can be called is
common knowledge; that Function instances have a built-in internal [[Call]]
method is not.

Far too detailed to be in the first sentences of a FAQ entry.
Functions can be called. That's what you need to know to use them.
That they have an internal [[Call]] property is an artifact of the
specification, and is only needed for reading the specification, not
for using the language.

/L

 

[Thomas 'PointedEars' Lahn]

So you admit you were wrong.

No, I am not. You are an idiot, who, despite being notified, is either
unable or unwilling to read postings in context. Go away.


PointedEars

 

[Thomas 'PointedEars' Lahn]

^^^^
I did not write *that*.

The specification

What exactly are you referring to with "The specification" here?

[…]
I.e., you are both correct (except ofcourse the part where you say
that John G. Harris is wrong),

In your humble opinion.

but "function object" would be both the more natural wording,

Not to a beginner. They do not care at this point about the object nature
of ECMAScript functions.

and the one closest to the way the specification is written.

Closest to the way the specification is written is obviously not best for
beginners. I maintain that it suffices here to say that a function is
created, then called.

as any beginner ought to be told.

[…]
But not there as it is missing the point. That a function can be called
is common knowledge; that Function instances have a built-in internal
[[Call]] method is not.

Far too detailed to be in the first sentences of a FAQ entry.
Functions can be called. That's what you need to know to use them.
That they have an internal [[Call]] property is an artifact of the
specification, and is only needed for reading the specification, not
for using the language.

You are not paying attention: that is *exactly* what *I* said.


PointedEars

 

[Thomas 'PointedEars' Lahn]

But not there as it is missing the point. That a function can be called
is common knowledge; that Function instances have a built-in internal
[[Call]] method is not.

Beginners need to be reminded, in one word, so that they will be able to
understand that
a.f = function ...
assigns an object to a.f.

It does not, but they do not care about that at that point anyway.

It is not pointless, of course. The term instance has a defined meaning in
OOP: It is something implicitly or explicitly *created* *by the programmer*
from a pre-existing template. Still I used it only to correct the false
statement; I did not suggest to put it there in the FAQ.

I agree. Same for "class", "singleton", etc. Using these terms to
describe JS only serves to confuse beginners (particularly those
experienced with other OO languages).

Apples and oranges.

There should be a FAQ topic that explains these terms and why they are
inappropriate for JS discussions.
No.

And the "instanceof" operator has an unfortunate name, which leads to
a lot of questions about its non-relationship with the "constructor"
property.
Where?

There should be a topic about that as well (assuming there isn't one
already).

Not until there is sufficient proof that it is a FAQ.


PointedEars

 

[David Mark]

But not there as it is missing the point.  That a function can be called
is common knowledge; that Function instances have a built-in internal
[[Call]] method is not.
Beginners need to be reminded, in one word, so that they will be able to
understand that
a.f = function ...
assigns an object to a.f.

It does not, but they do not care about that at that point anyway.

How do you figure it does not. Okay, it assigns a reference to a
Function object to a.f.

It is not pointless, of course.  The term instance has a defined meaning in
OOP: It is something implicitly or explicitly *created* *by the programmer*
from a pre-existing template.  Still I used it only to correct the false
statement; I did not suggest to put it there in the FAQ.

Okay, so don't put it in the FAQ.

Apples and oranges.


No.

And why not?

Here.


Not until there is sufficient proof that it is a FAQ.

Whatever. ISTM it has come up numerous times over the years.
Probably not as often of late.

 

[Thomas 'PointedEars' Lahn]

Okay, so don't put it in the FAQ.

Read my original suggestion and recognize the difference.

And why not?

It does not belong in a FAQ.

Here.

Message-IDs?


PointedEars

 

[John G Harris]

John G Harris wrote:


No, I am not. You are an idiot, who, despite being notified, is either
unable or unwilling to read postings in context. Go away.

No, I will not go away.

You proposed revised wording for the FAQ. I said your revision should be
improved. As usual, you exploded and provided a different improvement,
with ad hominem supplements.

I then pointed out that you had changed your original proposal. As
usual, you exploded and said you had not changed anything, with ad
hominem supplements.

I do not accept that text you suggest should be put in the FAQ can be
made more or less appropriate by the surrounding discussion, however
much it is "in context".

John

 

[John G Harris]

I always told before that using BNF non-terminals in docs and
discussions is only for spec implementers (or for those who discuss
exactly specs semantics). In casual explanations this BNF can look ugly
(that's the difference of a good written article from the spec copy-
paste).

So yeah, I also think this `FunctionExpression` is too technical (which
equals here "too ugly") for the FAQ explanation.

At least, "Function Expression" or even "function expression". Also the
correct naming from the common theory -- "functional expression" can be
used.

<snip>

I agree that FunctionExpression is not very readable so it would be
better split into separate words : Function Expression.

I disagree that any other words should be used. The syntax spec does
more than specify the syntax; it also gives names to things so they can
be talked about. E.g When specifying the semantics. The syntax spec
names have the big advantage that they are very precisely defined. There
is no doubt or fuzziness about the meaning of Function Expression,
Statement, etc, so much confusion is avoided.

You'll have noticed that Crockford uses 'statement' with a different
meaning, but he went to the trouble of defining his meaning with another
syntax specification. (Foolishly I think, but that's a different
discussion).

John