Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #14262

Re: function(){}() and subsequent calls

Message-ID <1970702.99vfnYFUyE@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2012-06-01 01:12 +0200
Subject Re: function(){}() and subsequent calls
Newsgroups comp.lang.javascript
References <z42dnVxvhJ19m1rSnZ2dnUVZ_vCdnZ2d@westnet.com.au> <jq74ed$s3p$1@news01.versatel.de> <fcidnaenHatRhFrSnZ2dnUVZ_qCdnZ2d@westnet.com.au> <jq84e2$u92$1@dont-email.me>
Followup-To comp.lang.javascript

Followups directed to: comp.lang.javascript

Show all headers | View raw


Matt McDonald wrote:

> On 12-05-31 01:12 AM, Andrew Poulos wrote:
>> Ah, so if I want it called immediately and still be available for
>> subsequent calls I tried this
>> var foo;
>> (foo = function(){})();
>> which "works" but JSLint says "Bad invocation".
> 
> JSLint (and by proxy, Crockford) desires the right
> parenthetical of an immediately invoked function expression
> to follow the invocation. An example follows.
> 
> `var foo = (function () {}());`
> 
> will pass JSLint (`"use strict";` dogma aside).

I, too, while I do not agree with several of Douglas Crockford's notions 
about these languages, recommend to use the latter form because it makes 
clear where the value assigned to the variable begins and where it ends.  
(Especially with source code editors that support highlighting of matching 
parentheses.  It is the *return value* of the function that is assigned, 
_not_ a reference to the function.)

However, I do not think that not using that form is the reason why the 
assignment above raises the "Bad invocation" error (or warning?) here.  
Instead, I assume it is because of the nature of the simple assignment 
operation in ECMAScript and its conforming implementations.

Many people – myself included, until a year or so ago – expect the result of 
an assignment operation to be the value that the property assigned to 
(variables are just special properties) has *after* the operation.  This 
view may be encouraged by using the grouping operator (the parentheses), 
where in math it means that the value of that expression must be calculated 
first, which also does apply to other uses of the grouping operator.  But in 
fact, somewhat counter-intuitively, the evaluation result of an assignment 
operation – and therefore the evaluation result of the grouping operator 
expression here – is the evaluation result of the *right-hand side* *before* 
assignment took place (ES1 to 5.1, section 11.13 [1]).

So what is called here is a Function instance that may end up not to be 
referred by the `foo' variable's value afterwards.  For example, assume that 
a property referred left-hand side has a setter that prevents it from 
changing value, or just changing value to a Function instance reference.  
Such has been possible before in conforming implementations for built-in 
properties (e.g. per ES3, §15.10.7.4), and in some implementations in a 
proprietary way for user-defined properties [2]; the possibility for the 
latter has been standardized in ECMAScript Edition 5, section 15.2.3, and 
possibly refined in the currently latest 5.1 Edition [3].

Yet, at first sight of this code you would expect `foo' to refer to that 
function from now on.  Therefore, this is potentially confusing code even 
for intermediates, and such code is just bad code.  I assume, although I 
cannot be sure, that this is the actual reason why JSLint rejects it.  It 
would be interesting to learn Douglas' rationale about it; unless he posts 
here again, that might be most easily found in "The Good Parts", which I 
have read only partially yet.


PointedEars
___________
[1] <http://ecma-international.org/ecma-262/5.1/#sec-11.13>
[2] 
<https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/DefineSetter>
[3] <http://ecma-international.org/ecma-262/5.1/#sec-15.2.3>
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

Back to comp.lang.javascript | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

function(){}() and subsequent calls Andrew Poulos <ap_prog@hotmail.com> - 2012-05-31 15:51 +1000
  Re: function(){}() and subsequent calls Holger Suhr <holgerholgerde@yahoo.de> - 2012-05-31 08:51 +0200
    Re: function(){}() and subsequent calls Andrew Poulos <ap_prog@hotmail.com> - 2012-05-31 17:12 +1000
      Re: function(){}() and subsequent calls Gregor Kofler <usenet@gregorkofler.com> - 2012-05-31 13:40 +0200
      Re: function(){}() and subsequent calls Matt McDonald <matt@fortybelow.ca> - 2012-05-31 09:57 -0600
        Re: function(){}() and subsequent calls Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-01 01:12 +0200

csiph-web