Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: David Mark on 21 May 2010 22:56 dhtml wrote: > 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 The only confusion there was your own. > 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 To wit. Presented with a choice of two patterns that produce the same result, an argument promoting the usefulness of the result is obviously a non-argument.
From: Dmitry A. Soshnikov on 22 May 2010 04:29 On 22.05.2010 3:01, Asen Bozhilov wrote: [...] > > Usually that approach is used for lookup optimizations, which is > complete useless, especially in this way. > Why is it useless? Name binding is present in the activation object, but not in some parent variable objects. There is a known disadvantage of course of such style -- you have to scroll code down to see, what is the passed value of formal parameter. Moreover, I think, that this style is the result of doubtful "coolness" when some has found out, that JS "can do so". The preferred is to define just local variables (which the same as formal parameter bindings are in the activation object) with the same values. E.g.: (function () { var document = document; ... })(); Nevertheless, there is one difference in case when a value is passed via formal parameter -- it will be assigned on entering the context stage. In contrast with defining local variable which real value (but the default /undefined/) is assigned at code execution phase. From this viewpoint, a variable has /two/ assignments. But, repeat, from the human code building, passing a value via parameter is less convenient, so personally, I would prefer to define a local variable. Dmitry.
From: Ry Nohryb on 22 May 2010 05:18 On May 22, 10:29 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > (...) > But, repeat, from the human code building, passing a value via parameter > is less convenient, so personally, I would prefer to define a local > variable. I don't: aQuery= (function (o, where, attr, value) { return (o.refresh= function (set, i, e) { o.length= 0, i= (set= where.getElementsByTagName('*')).length; while (i--) ((e= set[i])[attr] === value) && (o[o.length]= e); return o; })(); })([], document.body, "width", "100%"); aQuery.forEach(function (value, index, obj) { ... }); .. .. .. aQuery.refresh().forEach(function (value, index, obj) { ... }); -- Jorge.
From: Asen Bozhilov on 22 May 2010 05:47 Dmitry A. Soshnikov wrote: > Asen Bozhilov wrote: > > Usually that approach is used for lookup optimizations, which is > > complete useless, especially in this way. > > Why is it useless? Name binding is present in the activation object, but > not in some parent variable objects. > The preferred is to define just local variables (which the same as > formal parameter bindings are in the activation object) with the same > values. E.g.: > > (function () { > var document = document; > ... > > })(); You give the answer. I prefer to define local variables, too. When variables are defined on the top of the function code, the code is consistence and the reader can easy understand which values hold those variables. The maintaining of the code is better, because you can easy change the values of your local variables without scroll up and down. The only one case where can be used that approach is when someone want to share the `this' value of calling execution context to created by execution of that FunctionExpression. For exampple: (function (callingThis) { //.... })(this);
From: David Mark on 22 May 2010 07:34
Ry Nohryb wrote: > On May 22, 10:29 am, "Dmitry A. Soshnikov" > <dmitry.soshni...(a)gmail.com> wrote: >> (...) >> But, repeat, from the human code building, passing a value via parameter >> is less convenient, so personally, I would prefer to define a local >> variable. > > I don't: > > aQuery= (function (o, where, attr, value) { > return (o.refresh= function (set, i, e) { > o.length= 0, i= (set= where.getElementsByTagName('*')).length; > while (i--) ((e= set[i])[attr] === value) && (o[o.length]= e); > return o; > })(); > })([], document.body, "width", "100%"); That may be the most god-awful, convoluted mess I've ever seen (and I've seen jQuery, Dojo, etc., so that's really saying something). You're fired, El Abuelo. :) |