FAQ Topic - What is a function statement? (2010-05-24)
in [JavaScript]
|
From: Garrett Smith on 24 May 2010 19:12 On 5/24/2010 2:14 PM, Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: > >> By the way, I have any idea why they didn't standardized Function >> Statements in the 5th edition? >> Brendan's comments in the es-discuss message linked from the entry indicate that time was the matter. > var F; > if (true) { > F = function () { > //... > } > } > else { > F = function () { > //... > } > } > [...] That approach is used for function rewriting. The idea is to create a function gets the correct function, performing the test of which function to get in scope of the outer function. I like this pattern, which Richard has coined the "Russian Doll". With function rewriting, conditional tests are performed on an as-needed basis. If that function is never called, the feature tests are not performed. The practical implication is a function that may or may not be called. For example, the developer cannot be certain that the user will click on a button which triggers an event handler that he has coded. There are variations, but they basically boil down to something that resembles the following: myModule.meth = meth ; function meth (obj, type) { var meth; cond = typeof document.createDesktopApplication != "undefined"; if(cond) { meth = function(obj, type){ /*...*/ }; } else { meth = function(obj, type){ /*...*/ }; } (myModule.meth = meth)(obj, type); } Caveat: if `meth` nested function makes a `this` reference, it will not be `myModule` but global object or, in ES5, null. http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/a138478c647628f5/be985807130df58b?lnk=st&q=&rnum=2#be985807130df58b
From: Garrett Smith on 24 May 2010 19:17 On 5/23/2010 4:58 PM, kangax wrote: > On 5/23/10 7:00 PM, FAQ server wrote: >> ----------------------------------------------------------------------- >> FAQ Topic - What is a function statement? >> ----------------------------------------------------------------------- >> >> The term function statement has been widely and wrongly used to >> describe a ` FunctionDeclaration `. This is misleading because in >> ECMAScript, a ` FunctionDeclaration ` cannot appear as a Statement. >> To add to this confusion, some implementations, notably Mozillas', >> provide >> a syntax extension called function statement. This is allowed under >> section 16 of ECMA-262, Editions 3 and 5. > > MDC, unfortunately, doesn't describe Mozilla's function statements very > well, so I did it in NFE article, for anyone interested � > <http://yura.thinkweb2.com/named-function-expressions/#function-statements> > I've linked the article from the "what is (function{/*...*/})" entry and from the FAQ notes It's a great article and everybody should read it. Would it be redundant to link to it again from this entry? The "Functions" section has no main text. Perhaps the link could go there, provided something were written as a main entry for that section. > Curiously, older Safari (<=3.0.4) and some versions of Blackberry > browser implement function statements identically to Mozilla's extension. > Interesting. Maybe Safari changed to match IE so they could get badly authored IE-only sites working.
From: Dmitry A. Soshnikov on 25 May 2010 03:51 On 25.05.2010 1:14, Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: > >> By the way, I have any idea why they didn't standardized Function >> Statements in the 5th edition? >> >> That strange phrase from the spec /"ExpressionStatement cannot start >> with the *function* keyword because that might make it ambiguous with a >> FunctionDeclaration"/ is really strange -- because how then Mozilla >> distinguishes FD from FS? Easy I guess, by the context of the source >> code position. For what to write it in the spec (including 5th edition), >> if it is easy to distinguish? And I think for some it would be >> convenient to define functions in the declaration view. > > FunctionStatement does not provide any syntactical differences with > FD. But provides differences during instantiation stage. Function > Declarations are instated on entering on execution context, but > Function Statements during evaluation of the statement in which they > are defined. That provides a confusion in the readers of the code. For > example: > > if (true) { > function F(){ > //... > } > } > else { > function F(){ > //... > } > } > > F(); > > Which function will be invoked? Yes, you know the answer, Yes, I do. As the whole explanation above. But maybe your description will be useful for those who will be read this and don't know about it. > but that > example can be extended and code in these statement can be increased. > When you read the code you will be need to see parent statement to > catch that function is actually FS. That break readability of the code > and does not provide any benefits comparing with FunctionExpression > there can be assigned reference on variable. Actually if I modify that > example to use FunctionExpression the readability problem is gone away > and I think maintaining is better. > > var F; > if (true) { > F = function () { > //... > } > } > else { > F = function () { > //... > } > } > I think this is mostly relates to your habit. If it would obviously defined in the spec (even without mentioning a separate function type), but saying some small note e.g. "if FD appears a statement position, then it is created during the code execution". And that's all -- you have already another habit and it is convenient and readable for you. You don't even think that it is something strange. > When I need FunctionStatement behavior I always use > FunctionExpression. Of course you do, because if you program for the web, you (most likely) program cross-browsing. If you program only for particular implementation -- why just not to use all the additional features and sugar provided by the implementation? It is convenient. I used all the stuff -- let, array extras (even they weren't standardized yet -- I didn't think about it, I just used them) array comprehensions, __noSuchMethod__, etc programming one project only for Gecko implementation and was happy. I could also use function statements, but I don't remember that I did. Why? Don't know, maybe also just a habit to function expression for that. > That I do for readability and for unexpected > behavior which can be provided by extension on the language.These > extensions can be treat in different way in different > implementations. The current situation with "unexpected behavior" (which actually is expected, since we know the results in all major and minor implementations) is well known and goes without saying. Dmitry.
From: Dmitry A. Soshnikov on 25 May 2010 04:24 On 25.05.2010 3:12, Garrett Smith wrote: > On 5/24/2010 2:14 PM, Asen Bozhilov wrote: >> Dmitry A. Soshnikov wrote: >> >>> By the way, I have any idea why they didn't standardized Function >>> Statements in the 5th edition? >>> > > Brendan's comments in the es-discuss message linked from the entry > indicate that time was the matter. > In that reply in ML he said just some common phrase. That there were some more important things to do and that IE already has done some logical bugs (yes, they are, even if Brendan doubted how should FS be treated -- logically, by a conditional control flow it should be treated as Gecko treats, but not the IE of course). Anyway, as I said, I don't feel a big need in such functions (because already have a habit to use a FE in this case), but that just was interesting why if for Mozilla it was easy, then why the spec says that it is hard to distinguish (and the answer is simple -- they just used their own lexer/parser implementation). <snip> > > There are variations, but they basically boil down to something that > resembles the following: > > myModule.meth = meth ; > > function meth (obj, type) { > var meth; > cond = typeof document.createDesktopApplication != "undefined"; > if(cond) { > meth = function(obj, type){ /*...*/ }; > } else { > meth = function(obj, type){ /*...*/ }; > } > (myModule.meth = meth)(obj, type); > } > Yes, the pattern is known, but why do you use a separate `meth` function of the global context, and additionally `meth` method of the `myModule`? And after the `meth` function ends, it still the same, because used local var `meth` and it assigned to the method `meth`. Why no to do directly on `myModule.meth` all this implementation? Just an abstract example, I guess or there is something logical in it? Dmitry.
From: Ry Nohryb on 25 May 2010 05:11
On May 25, 9:51 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > (...) If it would obviously > defined in the spec (even without mentioning a separate function type), > but saying some small note e.g. "if FD appears a statement position, > then it is created during the code execution". And that's all (...) No that's not all: saying that would not be correct. -- Jorge. |