Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #14262
| 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
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
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