On Sat, Jan 1, 2011 at 12:00 PM, Dmitry A. Soshnikov <[email protected]> wrote: > On 01.01.2011 2:43, fernando trasvina wrote: >> >> Hi. very nice explanation but what i don't fully understand is why the >> grouping operator makes the parenthesis following the function declaration >> work as call. >> >> (function(x){alert(x)}(1)); >> >> why this is not treated the same way as: >> >> function(x){}(1); >> > > Because inside the grouping operator () there can be only an _expression_. > No matter in which way you place a function there (with a call or without > it) -- it's treated as FE (function expression). I.e. everything that is > placed inside the grouping operator is an expression. > > (1); // grouping operator with expression 1 > ("test"); // with expression "test" > (function () {}); // with a functional expression > > So in case when you have the following construction: > > (function (x) {alert(x)})(1); > > We have: > > 1. A grouping operator with a function(al) expression inside. It's exactly > the sign to the interpreter that this _something inside the grouping > operator_ should be _evaluated_ during the _execution_. I.e. we have a > function definition there. And this function definition is provided during > the runtime. > > 2. Applying (1) on the result of which is returned by the grouping operator > (i.e. our just created function). And notice, this is already exactly the > _call_ -- (1), but not a grouping operator as it was with a function > declaration (FD). > > Since FDs are created on entering the context stage (i.e. before the runtime > execution), obviously the following (1) _cannot_ be treated as a _call_. > Therefore, the parser considers theses as two constructions: FD and a the > following grouping operator: > > function foo(x){alert(x)}(1); // not a call, but syntactically correct > > > Backing to FEs. When you have the following construction: > > (function (x) {alert(x)}(1)); > > Again it's the sign to the interpreter that _something_ inside the grouping > operator should happen (evaluated) at runtime. And what is inside it doesn't > matter much at the stage of the parsing. When at runtime the interpreter > reaches this line, it just eval(uate)s the expression -- were the expression > is again -- creating the function and calling it. > > Notice though, that there is one subtle case related with these two similar > forms. > > // first function > var foo = function () { > return true; > } > > // second function > (function (x) {return x})(1); >
This was a similar example 'quiz' of last year: https://gist.github.com/147103 Semicolon are missing after FD so second statement result ends up being argument of first statement (forced) evaluation. -- Diego > The example above has an error (try to explain why). Thus, the following > example doesn't: > > // first function > var foo = function () { > return true; > } > > // second function > (function (x) {return x}(1)); > > Also, try to explain why. Though, the topic of the answer isn't related with > the discussed topic. How the answer will change if the `foo` function will > return an object of the other kind? > > Dmitry. > >> On Dec 31, 2010, at 7:46 AM, Dmitry A. Soshnikov wrote: >> >>> Just for those who don't use Twitter. I've just edited my >>> "ES3.Ch5.Functions" article in respect of explanation the "surrounding >>> parentheses". The thing is, that almost _all_ explanations (in books, >>> articles, etc) were at least very incomplete (and even wrong). >>> >>> So, why does this code produces a SyntaxError: >>> >>> function () { >>> ... >>> }() >>> >>> // or with name >>> >>> function foo() { >>> ... >>> }(); >>> >>> Try to provide as much complete explanation as possible. Also try to >>> answer without cheating ;) The correct and full explanation is here: >>> http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#question-about-surrounding-parentheses >>> >>> Dmitry. >>> >>> P.S.: Happy New Year! >>> >>> -- >>> To view archived discussions from the original JSMentors Mailman list: >>> http://www.mail-archive.com/[email protected]/ >>> >>> To search via a non-Google archive, visit here: >>> http://www.mail-archive.com/[email protected]/ >>> >>> To unsubscribe from this group, send email to >>> [email protected] > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
