Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: dhtml on 21 May 2010 11:47 On May 21, 4:45 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Andrea Giammarchi wrote: > >> new expression is basically an "elegant" module pattern recognizable > >> since the beginning. > > >> var o = (function () {}()); > > > Good, except the last parenthesis is in the wrong spot. > > ^^^^^^^^^^ > Opinions differ there. > The fact is that it's a matter of style. > >> var o = new function () {}; >
From: Andrea Giammarchi on 21 May 2010 13:10 On May 21, 11:02 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > I don't know. I stopped reading after that. ;) > I know what I wrote may not be clear for developers new JS, but did you actually get anything I wrote? That invocation was an example with absolutely nothing wrong in therm of parenthesis. I have already described in my blog the reason I think (function () {}()) is better than (function () {})() have a look. About the fact there is nothing inside was, again, an example ... whatever you return, included undefined ... this is *not* true with new function () {}, is this difficult to understand as concept? I think others got it, keep reading the rest. About all those arguments unrelated stories, you should read and try to understand and eventually ask what is not clear, before you start talking about flies and flowers ... I was simply explaining differences and whatever is not clear I can explain again. Please do not scam this ml with always your library ...it's quite boring, isn't it? best Regards
From: David Mark on 21 May 2010 13:38 Andrea Giammarchi wrote: > On May 21, 11:02 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> I don't know. I stopped reading after that. ;) >> > > I know what I wrote may not be clear for developers new JS, but did > you actually get anything I wrote? See above. > > That invocation was an example with absolutely nothing wrong in therm > of parenthesis. IBTD. > I have already described in my blog the reason I think > (function () {}()) is better than (function () {})() have a look. No thanks. > > About the fact there is nothing inside was, again, an example ... > whatever you return, included undefined ... this is *not* true with > new function () {}, is this difficult to understand as concept? I > think others got it, keep reading the rest. I'd just as soon not, but thanks again. > > About all those arguments unrelated stories, you should read and try > to understand and eventually ask what is not clear, before you start > talking about flies and flowers ... I was simply explaining > differences and whatever is not clear I can explain again. Clear as mud (as usual). Almost VK-esque. I can rarely make heads or tails of your stuff (the prose, not the script). > > Please do not scam this ml with always your library ...it's quite > boring, isn't it? Even if you meant _spam_ this _ng_, you would still be wrong. > > best Regards Same! :)
From: dhtml on 21 May 2010 18:14 On May 21, 4:27 am, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On May 20, 10:50 pm, Andrea Giammarchi wrote: > > > new expression is basically an "elegant" module pattern > > recognizable since the beginning. > > > var o = (function () {}()); > > > what can "o" be? just everything, included undefined. > > Might this not be a case of solving the wrong problem? Wouldn't it be > possible to chose an Identifier for use in place of 'o' that told the > reader of the code enough about the value that the variable was > expected to hold that they did not need to look any further unless > debugging showed evidence that the actual value was not consistent > with the expectation? > > > var o = new function () {}; > > > what can "o" be in above case? Inevitably an object ;-) > > <snip> > > An object, but not necessarily the object that resulted from - new - > operation, and possibly a function, Date, RegExp, String, host, etc. > object. The use of the - new - operator really only grantees that the > value will not be a primitive, which isn't such a great step forward. > With `new`, the invocation is at the beginning of an expression so it is immediately apparent. With a CallExpression it is at the end. var animalBuilder = new function() { /*...*/ }; As you pointed out, a constructor may have an explicit return statement and return an object. But if it is used with a NewExpression, why would it? An anonymous function might have any reason for not being called immediately. There is a lot of code that does things like that and for good reason. For example: var animalBuilder = function() { /*...*/ }; A NewExpression with a FunctionExpression is perfectly valid and fine to use. The only problem is confusion, which has been demonstrated by the misconceptions that have been posted. Those misconceptions are: 1) it might not return an object 2) it is an awful choice 3) it cannot accept Arguments 1) False. A new expression will always result in an object being created and returned unless the function throws an error. 2) In the right context, it is a good option 3) False, as shown It is confusing to beginners. Like anything, there is potential for misuse. One type of misuse is where only a closure is needed and the code does not assigning to `this` and discards the result. Using new expression with function expression is fine. Once the mechanics are understood (and they really are quite simple), the pattern should not be confusing.
From: Asen Bozhilov on 21 May 2010 19:01
dhtml [Garrett Smith] wrote: > A NewExpression with a FunctionExpression is perfectly valid and fine > to use. The only problem is confusion, which has been demonstrated by > the misconceptions that have been posted. Those misconceptions are: > 3) it cannot accept Arguments That statement is not correct. The semantic of NewExpression by ECMA-262 is: | new NewExpression | new MemberExpression Arguments So the follow code is valid and pass list of arguments to internal [[Construct]] method of the object referred by the value of MemberExpression. new function(x, y){ print(x * y); //10 }(2, 5); Of course that code is confused, especially for beginners. The whole point with passing arguments to FunctionExpression which is called right after creation, is useless practice. FunctionExpression itself is lexical closure, because during evaluation of FunctionExpression, will be created object on which internal [[Scope]] property refer AO/ VO of execution context in which is evaluated that FunctionExpression. From that point, every FunctionExpression called right after creation can get the values of variables/functions defined in calling execution context via Scope Chain. Usually that approach is used for lookup optimizations, which is complete useless, especially in this way. |