From: Garrett Smith on
abozhilov wrote:
> Garrett Smith wrote:
>
>> 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.
>
> Yes, but in the other hand. If people don't know how property resolve
> against Prototype chain, they cannot understand, how identifier
> resolve against Scope Chain. Scope Chain contain Variable Objects.

That makes sense.

> ECMA 262 standard, doesn't specify implementation of AO/VO. From that
> point, AO/VO can have [[Prototype]] property, which refer next
> `object' in Prototype chain. And during Identifier Resolution
> algorithm specified in `10.1.4 Scope Chain and Identifier Resolution`
> will check for existing in Prototype chain of next `object' in Scope
> Chain, for property with name as `Identifier` from step 2:
>

The VO may be technically allowed have a prototype, but it can cause
problems when it does. The only observed implementation where VO had a
[[prototype]] was BB9k.

[...]

[...]

> And of course, in archive of newsgroup have brilliant explanations
> from Thomas and Richard. I thing, we can create very good article,
> which is useful for people whose want to know how Prototype
> inheritance work in ECMA-262 implementations.
>
Alright.

What do you think of the FAQ Entry proposal for a section on Functions?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dmitry A. Soshnikov on
On 28 фев, 15:35, abozhilov <fort...(a)gmail.com> wrote:
> Garrett Smith wrote:

> > I can write or, you can write it :-D. Maybe you can enlist some help
> > like kangax or Dmitry or David Mark.
>
> Yes. If you have time and desire for writing this article. We can help
> you. For example Dmitry has article for Prototype inheritance in
> ECMA-262 implementations on Russian.
>
> <URL:http://dmitrysoshnikov.com/ecmascript/ru-chapter-7-1-oop-general-theory/
>
> <URL:http://dmitrysoshnikov.com/ecmascript/ru-chapter-7-2-oop-ecmascript-i...
>

By the way, chapter 7 is already translated, and now is waiting (in
drafts) for kanax's check for wording mistakes. If somebody who know
English perfectly (of for whom English is a native language) can check
it also, it will be good.

Today I've also finished translation of "Chapter 6.
Closures" (meanwhile Richard's article is about exactly technical part
in ES, mine is mostly about the general theory), so evereone is
welcome for reading, correction of English words mistakes and
technical additions.

Dmitry.
From: Asen Bozhilov on
Garrett Smith wrote:

> What do you think of the FAQ Entry proposal for a section on Functions?

Yes. It can be usefully, especially for people, which start learning
JavaScript. And with addition from kangax article, they can get
answers on their questions.
Regarding:

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

If i am beginner in ECMAScript. Perhaps i will have other questions,
related with this case. For example:
Why you wrap in parenthesis `(function(){})` instead of `function(){}
`?

Kangax has explanation about this:
| A somewhat less obvious example of function expression
| is the one where function is wrapped with parenthesis —
| (function foo(){}).
| The reason it is an expression is again due to a context: "(" and
")"
| constitute a grouping operator and grouping
| operator can only contain an expression:

Explanation is good, but miss some important part from ECMA-262:

| 12.4 Expression Statement
| ExpressionStatement :
| [lookahead {{,function}] Expression ;
| Note that an ExpressionStatement cannot start with
| an opening curly brace because that might make it ambiguous
| with a Block. Also, an ExpressionStatement cannot start
| with the function keyword because that might make it
| ambiguous with a FunctionDeclaration.

And the second question can be. Why there isn't semicolon on the end
of Expression Statement?


From: Dr J R Stockton on
In comp.lang.javascript message <hmaje7$49a$1(a)news.eternal-
september.org>, Fri, 26 Feb 2010 23:59:56, Garrett Smith
<dhtmlkitchen(a)gmail.com> posted:

> 4.1 What is (function(){ /*...*/ })() ?

Add : It is a call of a function with no arguments, the body of which is
indicated as (choose) { /*...*/ } or /*...*/ .

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

Just creating an anonymous function should have no effect; doing nothing
is more efficient.


Instead :
Variables declared in an anonymous 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.

There should be a minimal example in the FAQ proper.


At the moment, [www.]jibbering.com returns me no page content.

Except in a link to a book, the most recent version of the FAQ that I
have has no reference to closures; the word needs an explanation before
it is first used in Section 4.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
From: kangax on
On 2/28/10 4:49 PM, Asen Bozhilov wrote:
> Garrett Smith wrote:
>
>> What do you think of the FAQ Entry proposal for a section on Functions?
>
> Yes. It can be usefully, especially for people, which start learning
> JavaScript. And with addition from kangax article, they can get
> answers on their questions.
> Regarding:
>
> | (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.
>
> If i am beginner in ECMAScript. Perhaps i will have other questions,
> related with this case. For example:
> Why you wrap in parenthesis `(function(){})` instead of `function(){}
> `?
>
> Kangax has explanation about this:
> | A somewhat less obvious example of function expression
> | is the one where function is wrapped with parenthesis �
> | (function foo(){}).
> | The reason it is an expression is again due to a context: "(" and
> ")"
> | constitute a grouping operator and grouping
> | operator can only contain an expression:
>
> Explanation is good, but miss some important part from ECMA-262:
>
> | 12.4 Expression Statement
> | ExpressionStatement :
> | [lookahead {{,function}] Expression ;
> | Note that an ExpressionStatement cannot start with
> | an opening curly brace because that might make it ambiguous
> | with a Block. Also, an ExpressionStatement cannot start
> | with the function keyword because that might make it
> | ambiguous with a FunctionDeclaration.

Hmm. This is somewhat mentioned later on, when explaining why function
declarations are not allowed in blocks
(<http://yura.thinkweb2.com/named-function-expressions/#function-declarations-in-blocks>).

To quote:

"FunctionDeclarations are only allowed to appear in Program or
FunctionBody. Syntactically, they can not appear in Block ({ ... }) �
such as that of `if`, `while` or `for` statements. This is because
Blocks can only contain Statements, not SourceElements, which
FunctionDeclaration is. If we look at production rules carefully, we can
see that the only way Expression is allowed within Block is when it is
part of ExpressionStatement. However, ExpressionStatement is explicitly
defined to not begin with "function" keyword, and this is exactly what
makes FunctionExpression invalid as part of a Statement or Block (note
that Block is merely a list of Statements).

Because of these restrictions, whenever function appears in a block
(such as in previous example) it should actually be considered a syntax
error, not function declaration or expression. The problem is that none
of the implementations I've seen parse these functions per rules. They
interpret them in proprietary ways instead."

(and chapter on function statements follows...)

I also remember answering similar question � "what's the difference
between (function(){})() and (function(){}())?":

<http://groups.google.com/group/comp.lang.javascript/msg/1f31cddaa2e10c3e>

Looking at last example in that message (function(){}()), I now realize
that I should have mentioned the cause of failure � expression statement
can not begin with `function`.

--
kangax