From: Johannes Baagoe on 20 Apr 2010 15:28 Garrett Smith : > Johannes Baagoe : >>> nick : >>>> "Some JavaScript engines, not including SpiderMonkey, incorrectly >>>> treat any function expression with a name as a function definition" >> In a sort of lame defence (why on earth am I trying to excuse >> Microsoft?), > If you're asking me to guess, I would say that you have probably > mistaken "function definition" with "function declaration". I hope not. I talk about a function expression with a name. As I understand it, that is a realisation of FunctionExpression : function Identifier opt ( FormalParameterList opt ) { FunctionBody } in which the optional Identifier (the "name") exists. > I suggest you to and read the ECMA-262 specification for "Function > Definition". I have, just in case, but I didn't need to: my memory was quite accurate. -- Johannes
From: Johannes Baagoe on 20 Apr 2010 15:38 Stefan Weiss : > Didn't you say (in a different thread) that you "quite liked" Jorge's > loop() function? That's a named function expression, too. It doesn't > have to be - you could just call loop() separately from its definition - > but the way you're using it on > > http://baagoe.com/en/RandomMusings/javascript/time.js > > it's still a named function expression. Touché. You are right about that one. I shall correct the matter forthwith. > Do you deserve a terrible fate now? ;-) Well, yes: having to confess that my behaviour does not always match my words :) And publicly, too. -- Johannes
From: Garrett Smith on 20 Apr 2010 16:05 Johannes Baagoe wrote: > Garrett Smith : >> Johannes Baagoe : >>>> nick : > >>>>> "Some JavaScript engines, not including SpiderMonkey, incorrectly >>>>> treat any function expression with a name as a function definition" > >>> In a sort of lame defence (why on earth am I trying to excuse >>> Microsoft?), > >> If you're asking me to guess, I would say that you have probably >> mistaken "function definition" with "function declaration". > > I hope not. I talk about a function expression with a name. As I > understand it, that is a realisation of > > FunctionExpression : > function Identifier opt ( FormalParameterList opt ) { FunctionBody } > > in which the optional Identifier (the "name") exists. > >> I suggest you to and read the ECMA-262 specification for "Function >> Definition". > > I have, just in case, but I didn't need to: my memory was quite accurate. > Then what is wrong with an implementation treating a FunctionExpression as a Function Definition? And if the answer is nothing (which is the correct answer) then why insist Microsoft got that wrong? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Stefan Weiss on 20 Apr 2010 16:14 On 20/04/10 21:12, Johannes Baagoe wrote: > Stefan Weiss : >> and when you want to recurse from inside a function expression. > > What is wrong with > > var fact = function(n) { > if (n > 0) { > return n * fact(n - 1); > } else { > return 1; > } > }; > > ? It works, of course, but it makes the recursion dependent on a (potentially unrelated) variable from an outer scope. I don't think the implementation of a function should need to care about which variable it will be assigned to. And then there are the "self-executing" functions from your original examples, which run before their result is assigned to a variable: var foo = (function () { // what if I want to recurse here? })(); BTW, I prefer this style of parenthesis placement, but I think both are fine as long as the intention is clear. -- stefan
From: Johannes Baagoe on 20 Apr 2010 17:34
Stefan Weiss : >Johannes Baagoe : >> var fact = function(n) { >> if (n > 0) { >> return n * fact(n - 1); >> } else { >> return 1; >> } >> }; > It works, of course, but it makes the recursion dependent on a > (potentially unrelated) variable from an outer scope. I don't think the > implementation of a function should need to care about which variable it > will be assigned to. Good point. One can enclose them in yet another function, though, but I'm not sure that makes things clearer. > And then there are the "self-executing" functions from your original > examples, which run before their result is assigned to a variable: > var foo = (function () { > // what if I want to recurse here? > })(); You are right, I can't. If I want to define 21! inline using neither named function expressions nor function declarations, the best I have come up with is ((function() { return fact = function(n) {return n > 0 ? n * fact(n - 1) : 1;}; }())(21)); which is hardly a model of legibility. So there may legitimate uses for named function expressions after all. The trouble is that their formal definition is so badly ambiguous that I immediately object on aesthetic if not on sound theoretical grounds, but I admit that if the implementations always get it right, it becomes little more than a matter of taste. (Of course, if MDC doesn't lie, some implementations *don't* get it right, which gives rather more weight to my theoretical pretexts.) -- Johannes |