Closing parenthesis in function's definition followed by itscall
in [JavaScript]
|
From: Johannes Baagoe on 22 Apr 2010 05:03 Ry Nohryb : > Guess what would drive people away from writing it so : > > var fact21 = (function fact (n) { > return n > 0 ? n * fact(n - 1) : 1; > })(21); From: The Boss To: Software developers Subject: Unnecessary cuteness in production code It has come to my attention that several software developers have fallen into the habit of writing terse code that requires lengthy explanations when straightforward self-explanatory code would serve equally well. This is to stop immediately. We are in the business of serving the customers' needs, not the technical staff's egos. -- The Boss.
From: Marco Mariani on 22 Apr 2010 05:56 On 04/22/2010 11:45 AM, VK wrote: > But I do *not* hate IE in particular for kipping the original > FunctionExpression behavior or having a slightly different elision > treatment in array declarations. These two are "fixation points" of > Brendan Eich, not mine - he runs with them for years and puts nearly > on each ECMA committee session, at least used to. For me these are > laughable nuisance points to prove someone "evilness". Maybe it's because those nuisances can easily be fixed, while fixing the behaviour (or the very existence) of 'undefined' would basically require a time machine.
From: Johannes Baagoe on 22 Apr 2010 06:43 Ry Nohryb : > The "do NOT use named FEs" advice that has spread far and wide. I rather think I shall continue to spread it, although I have somewhat softened my position - the "recursion" argument does make sense. Still, I prefer to affect the inner function to a variable in the outer function's scope, and I haven't been convinced that there is a significant disadvantage in doing so. But my reasons for doing so has nothing to do with that bug I didn't even know existed. It because I like to think of function f() {/*...*/} as a mere shorthand, a.k.a. "syntactical sugar", for var f = function() {/*...*/}; (I suspect that this is not true, and I expect to be told in elaborate detail why it only shows a lamentable ignorance of the specs, for which I shall be duly grateful. But my point is that in some future, simple language for beginners, that is how it *should* be. Actually, I would prefer to see function declarations disappear altogether, if it were not for legacy that cannot be easily dismissed.) > Just another bit of Microsoft's (evil) legacy for the web. Look - in my entire existence, I have bought *one* Microsoft product with my own money: the BASIC that came with the, IIRC, "Floating Point Memory Extension Card" for my Apple II. So I am hardly a Microsoft fan, and I have just saved my mother-in-law 140 € by insisting that the computer she is going to buy this afternoon (and that I am likely to have to maintain) run Ubuntu. But I believe that this crusade is counter-productive. Rather than bashing Microsoft, or for that matter anybody else, promote better alternatives. -- Johannes
From: Stefan Weiss on 22 Apr 2010 09:16 On 22/04/10 14:45, VK wrote: > On Apr 22, 2:42 pm, VK <schools_r...(a)yahoo.com> wrote: >> ( function foo() {/*...*/} )() >> ^__________________________^ >> foo visibility scope > > Correction: not even that. The specs reading they came back on the > market is not describable at all in any common scope terms because in > say Firefox > > var a = ( function f(){return 1}() + 1 ); > window.alert(a); // 2 > > but > > var a = ( function f(){return 1}() + f() ); > window.alert(a); // Error: f is not defined > > So trying to express it in some human way, "within an expression a > FunctionExpression gets an implicit temporary scope and is not visible > to the rest of the expression; this implicit temporary scope gets > destroyed after the containing expression is evaluated". Could it be that you're just confused about the parentheses? They have nothing at all to do with scope and visibility. The only reason they are sometimes required is to make a function *expression* out of what would otherwise be a *declaration*. In both your examples, the parentheses are redundant, because the "f" function is already in expression form. The "f" identifier is only visible inside the function *body*, which is consistent with JS's function-as-scope paradigm. Microsoft breaks that rule by making "f" available outside the function body - and not only that: IE doesn't even need the expression to be evaluated at all. It simply confuses NFE with function declarations: function ouch () { alert(typeof foo); // "function" - this is correct alert(typeof bar); // IE: "function"; others: "undefined" return; // evaluation stops here! function foo() {} var unused = function bar() {}; } (Note that there are no parentheses around the function expression) Now, are you still calling that a feature in MSIE? -- stefan
From: Johannes Baagoe on 21 Apr 2010 08:48
Garrett Smith : > Johannes Baagoe : >> 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. > Or design. Of course. 51090942171709440000 is much more efficient. But that isn't the point. I try to figure out whether there are cases where function expressions need be named, or at least are better named. My starting position is (or was) "No, named functions are creatures of the darkness - their syntax sucks by mixing two notions in a way that is bound create to confusion, for no benefit at all". (And Microsoft has *nothing* to do with the matter, I didn't suspect that *other* objections to named function expressions were part of a holy war.) However, as Stefan Weiss and others rightly point out, there appears to be at least one case where names for function expressions are definitely useful: when the function expression calls itself. There are alternatives, but they are not clearly better, and in the case of my rather quixotic attempt above, clearly worse. -- Johannes |