From: Dmitry A. Soshnikov on
On Mar 1, 12:49 am, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote:

[...]

>
> | (function(){ /*...*/ })()
>
> It is expression statement. During evaluation of CallExpression, will
> create `object', which has [[Call]] method. Internal [[Scope]]
> property of created `object' refer the object which is on the front of
> Scope Chain. And after that will be invoked [[Call]] method with
> passed primitive value `null' as the this value. After evaluation of
> this expression, created object, will be marked for garbage
> collection, because there aren't any references to this object.

Although, it's correct, it's too complex and to detailed for the
exactly *FAQ entry*. A FAQ entry should be as easy as possible in
explanation. And for all other interested deeply in subject, already
show more detailed explanation. So for novice all that "[[Call]]",
"[[Scope]]", "object refer by" and so on -- are not so interested in
exactly FAQ entry.

I would suggest something simpler, e.g.:

"This is anonymous function which is called right after creation. For
the grammar rules such form should be converted to expression
statement (e.g. with using grouping operator as shown in example).
Such concept is usually used for creating encapsulated scope for
initialization purpose -- additional helper variables and functions
defined withing this won't be polluted to the outside".

After that a small (abstract) example, e.g.:

var myObject = {};

// initialization
(function (object) {

var _someData = 10;
myObject.someFn = function () {
return _someData;
};

})(myObject);

And after that -- link on more detailed explanation, e.g. as yours:
"More detailed..." (maybe with opening hidden previously block
bellow).

P.S.: But regarding the subject your explanation is very good and has
everything needed in such compact form.

Dmitry.
From: Richard Cornford on
On Feb 27, 7:59 am, Garrett Smith wrote:
> The subject of functions comes up enough that it warrants a
> section in the FAQ. The section could be inserted before
> dates.
>
> Of the questions on functions, the most common is that of
> anonymous functions used to create closures, so as
>
> 4 Functions
> 4.1 What is (function(){ /*...*/ })() ?
>
> 5 Dates
> 5.1 How do I...
>
> Functions are often used to create scope.
>
> By creating an anonymous function, the variables in that function
> are not accessible from outside the function. This is desirable
> for example, to hide implementation details or avoid polluting
> the global scope.
>
> For more information, please see:
>
> yura.thinkweb2.com/named-function-expressions/
> http://www.jibbering.com/faq/notes/closures/
>
> I would also like to fix an error in the closures article from:
>
> | The instance of MyObject2 referred to by the objectRef variable
> | has a prototype chain. The first object in that chain is the
> | instance of MyObject1 that was created and assigned to the
> | prototype property of the MyObject2 constructor. The instance
> | of MyObject1 has a prototype, the default Object prototype
> | that corresponds with the object referred to by
> | Object.prototype. Object.prototype has a null prototype so
> | the prototype chain comes to an end at this point.
>
> to:
>
> | The instance of MyObject2 referred to by the objectRef variable
> | has a prototype chain. The first object in that chain is the
> | instance of MyObject1 that was created and assigned to the
> | prototype property of the MyObject2 constructor. The next object
> | in that chain is the [[Prototype]] of the MyObject1 instance;
> | it is MyObject1.prototype. The next object in the chain is the
> | [[Prototype]] of MyObject1.prototype, which is Object.prototype.
> | Object.prototype has a null [[Prototype]] so the prototype
> | chain comes to an end at this point.
> |
> | Prototype Diagram
> | objectRef [[Prototype]] -> MyObject1 [[Prototype]] ->
> | MyObject1.prototype [[Prototype]] -> Object.prototype.
>
> I also propose the removal that the final paragraph of that section
> (below). The article already discusses [[Prototype]], but uses the
> term "prototype" to describe it. I prefer to use the spec's
> [[Prototype]] notation to avoid confusion between a Function's
> prototype property and Objects' internal [[Prototype]] property.

Objects in ECMAScript have prototypes, and calling them an object's
prototype is completely appropriate. "[[Prototype]]" is the name of
the internal property of the object that refers to its prototype (or
the first object on its prototype chain). It might be acceptable for
people familiar with ECMAScript and its prototypes to use
"[[Prototype]]" as a shorthand for an object's prototype chain but
that usage is inappropriate in the closures document.

Use:-

| The instance of MyObject2 referred to by the objectRef variable has
| a prototype chain. The first object in that chain is the instance
| of MyObject1 that was created and assigned to the prototype
| property of the MyObject2 constructor. The instance of MyObject1
| has a prototype, the object originally assigned to the MyObject1
| function's prototype property by default (and which has no
| properties of its own). That object has a prototype, the default
| Object prototype that corresponds with the object referred to by
| Object.prototype. Object.prototype has a null prototype so the
| prototype chain comes to an end at this point.

The proposed diagram is inappropriate.

In "Other Examples" change the URL behind "the emulation of private
static members for ECMAScript objects" from:-

http://www.litotes.demon.co.uk/js_info/private_static.html

<URL: http://myweb.tiscali.co.uk/cornford/js_info/private_static.html
>

- as the latter is functional.

> Propose to remove:
> | Note: ECMAScript defines an internal [[prototype]] property of
> | the internal Object type. This property is not directly
> | accessible with scripts, but it is the chain of objects referred
> | to with the internal [[prototype]] property that is used in
> | property accessor resolution; the object's prototype chain. A
> | public prototype property exists to allow the assignment,
> | definition and manipulation of prototypes in association with
> | the internal [[prototype]] property. The details of the
> | relationship between to two are described in ECMA 262 (3rd
> | edition) and are beyond the scope of this discussion.

Don't do that.

Richard.
From: Richard Cornford on
On Feb 28, 8:49 am, Garrett Smith wrote:
<snip>
> I too felt the discussion of [[Prototype]] chain was a bit out
> of place in that article. My intent was to preserve the
> article, move it to a /faq/notes/, as has been discussed, and
> in the process, fix an error and add some navigation.
<snip>

You absolutely should not move the closures article. The reasons for
doing so were utterly spurious to start with, but you absolutely must
maintain the original URL as it is linked to from many other articles
(and even referenced by URL in books and PDF publications). Having two
copies on the server would eventual result in them diverging, which
would not be a good idea. Redirecting from one URL to the other would
be acceptable, so long as that redirect could be guaranteed to be
maintained indefinitely (which seems very unlikely).

Richard.
From: Garrett Smith on
Richard Cornford wrote:
> On Feb 28, 8:49 am, Garrett Smith wrote:
> <snip>
>> I too felt the discussion of [[Prototype]] chain was a bit out
>> of place in that article. My intent was to preserve the
>> article, move it to a /faq/notes/, as has been discussed, and
>> in the process, fix an error and add some navigation.
> <snip>
>
> You absolutely should not move the closures article. The reasons for
> doing so were utterly spurious to start with, but you absolutely must
> maintain the original URL as it is linked to from many other articles
> (and even referenced by URL in books and PDF publications). Having two
> copies on the server would eventual result in them diverging, which
> would not be a good idea. Redirecting from one URL to the other would
> be acceptable, so long as that redirect could be guaranteed to be
> maintained indefinitely (which seems very unlikely).
>
I do not intend to edit content under /faq/faq_notes/. Some of the
content is a out of date and less relevant. One of the things that the
previous FAQ and notes did very badly is navigation.

Meaningful fragids have replaced things like "#FAQ2_10". Those "NUMID"
fragids are from the old organization of the FAQ. The sooner they become
irrelevant, the sooner they can be removed. Obviously while the FAQ
notes is linking to "FAQ2_10", that isn't going to happen, so changing
the links of the FAQ notes to link to the new fragids of the FAQ is
desirable.

The content of those notes articles can be edited and modified for
corrections, clarifications, and presentational updates, including
navigational links, CSS changes, HTML cleanup.

The location "/faq/notes/" is easier to remember and simpler than
"faq/faq_notes/faq_notes.html" and the same is true for the other URI
changes.

The documents under /faq/faq_notes/ can be changed to use an http
redirect using a meta tag.

The documents under /faq/notes/ will have navigation and thus better
SEO. Links from the FAQ to the /faq/notes/ location can be reciprocated,
and not by pointing to outdated "NUMID", e.g. a link to the
"localization" section would be to "/faq/#localization" and not "FAQ2_10".
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on
Dmitry A. Soshnikov wrote:
> On Mar 1, 12:49 am, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote:

[...]

> I would suggest something simpler, e.g.:
>
> "This is anonymous function which is called right after creation. For
> the grammar rules such form should be converted to expression
> statement (e.g. with using grouping operator as shown in example).
> Such concept is usually used for creating encapsulated scope for
> initialization purpose -- additional helper variables and functions
> defined withing this won't be polluted to the outside".
>

I'll take the first sentence of that. What Stockton and I both worked on
covers the rest well enough (below).

> After that a small (abstract) example, e.g.:
>
[...]

>
> And after that -- link on more detailed explanation, e.g. as yours:
> "More detailed..." (maybe with opening hidden previously block
> bellow).
>

That is getting into how to use closures. That is an important topic.
Perhaps it is too much for FAQ Entry itself, though.

Other closure patterns include "function rewriting", "module pattern",
Factory, Singleton, memoization. I'd like to add a link to the closure
patterns mini-site that explains each and link to that but there isn't
any such site.

Maybe just a link to something that explains that type of usage, e.g.
"module pattern"?

> P.S.: But regarding the subject your explanation is very good and has
> everything needed in such compact form.
>
It's very easy to get carried away and write too much. I think simple
would be better.

Taking a combination of what you, I, and Stockton have written:

This is an anonymous FunctionExpression which is called right
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.

The reader does not need a complete technical definition of
FunctionExpression. He either already knows what that is or he is being
gently introduced to a new term.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/