Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: Ry Nohryb on 22 May 2010 08:10 On May 22, 1:34 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Ry Nohryb wrote: > > > 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). It's awesome, yeah, truly awesome. And didactic, too: it shows that expressions' values are there for you to use them, that local vars are not any better than named params, that immediate function calls provide a good chance to initialize all of them on the fly using 0 additional lines, that the var keyword is often superfluous, that boolean operators are perfect flow controllers, that it's useless to wrap single-line blocks in braces, and that JS can be made to look very much like the most delightful of C code. > You're fired, El Abuelo. :) Nah! -- Jorge.
From: Dmitry A. Soshnikov on 22 May 2010 09:40 On 22.05.2010 16:10, Ry Nohryb wrote: > On May 22, 1:34 pm, David Mark<dmark.cins...(a)gmail.com> wrote: >> Ry Nohryb wrote: >> >>> 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). > > that local vars are > not any better than named params, Of course they are not (and local vars even worse from the already mentioned viewpoint -- they have /two/ assignments (initial - on entering, and real - at execution)). The only lack (and is very inconvenient lack) is that I (analyzing your code) should (and we suppose it's more than you small example with 7 lines) scroll first to the end (to the call expression) to see, what are the values of some strange names "o, where, attr, value" and then go back to continue analyze the code -- yes, again scrolling up. That's it. There is no any other lacks and from the assignments "issue" formal parameter for that purpose even win the local vars. > that immediate function calls > provide a good chance to initialize all of them on the fly using 0 > additional lines, Yes, that's true. Also there is one important exception when passing via formal parameter is needed -- already mentioned by Asen passing /this/ value (if you assumes that inside the function context it will have other value). > that the var keyword is often superfluous It's the matter of taste. So let's leave it for that. Everyone can choose his own style. There are pros and cons. And if in case of local vars cons are mostly theoretically-technical (/two/ assignments -- who cares?), then in case of passing via arguments cons are exact and real -- inconvenience for a programmer. Tacking into account that both name binding will be in the same place (a property of an activation object), I prefer to use local vars. But, it isn't my rule -- I do so most the time, but also can be a case whey I pass them via arguments. Why? Because I just want so and free to do so. > that > boolean operators are perfect flow controllers, Is it about the topic or this is about something else? Show me an example. > that it's useless to > wrap single-line blocks in braces, The same, I didn't get it. Is it relevant or this is from other song? And by the way, wrapping a single-line block in braces can also for convenience: var a = (bla ? blu : ble). It's just a matter of taste. Dmitry.
From: Johannes Baagoe on 22 May 2010 10:22 Dmitry A. Soshnikov : > Is it relevant or this is from other song? I think it is from another song. Ry Nohryb likes cute constructs that minimise code lines. Most other contributors frown upon anything the average programmer may fail to understand and maintain. -- Johannes
From: Ry Nohryb on 22 May 2010 10:26 On May 22, 3:40 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On 22.05.2010 16:10, Ry Nohryb wrote: > > > that local vars are > > not any better than named params, > > Of course they are not (and local vars even worse from the already > mentioned viewpoint -- they have /two/ assignments (initial - on > entering, and real - at execution)). > > The only lack (and is very inconvenient lack) is that I (analyzing your > code) should (and we suppose it's more than you small example with 7 > lines) scroll first to the end (to the call expression) to see, what are > the values of some strange names "o, where, attr, value" and then go > back to continue analyze the code -- yes, again scrolling up. > > That's it. There is no any other lacks and from the assignments "issue" > formal parameter for that purpose even win the local vars. function qGen (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; })(); } aQuery= qGen([], document.body, "width", "100%"); > > > that immediate function calls > > provide a good chance to initialize all of them on the fly using 0 > > additional lines, > > Yes, that's true. Also there is one important exception when passing via > formal parameter is needed -- already mentioned by Asen passing /this/ > value (if you assumes that inside the function context it will have > other value). But that's not any "important exception", afaics, for you can't shadow "this". Passing it as a parameter just captures it, no matter what it is, be it the outer this or anything else. > > that the var keyword is often superfluous > > It's the matter of taste. So let's leave it for that. Everyone can > choose his own style. There are pros and cons. And if in case of local > vars cons are mostly theoretically-technical (/two/ assignments -- who > cares?), then in case of passing via arguments cons are exact and real > -- inconvenience for a programmer. > > Tacking into account that both name binding will be in the same place (a > property of an activation object), I prefer to use local vars. But, it > isn't my rule -- I do so most the time, but also can be a case whey I > pass them via arguments. Why? Because I just want so and free to do so. I usually declare locals as params. > > that > > boolean operators are perfect flow controllers, > > Is it about the topic or this is about something else? Show me an example.. That instead of if (a) { b() } you can just write a && b(); > > that it's useless to > > wrap single-line blocks in braces, > > The same, I didn't get it. Is it relevant or this is from other song? > And by the way, wrapping a single-line block in braces can also for > convenience: var a = (bla ? blu : ble). It's just a matter of taste. Yes, this parens are useless, where do they come from ? :-) -- Jorge.
From: David Mark on 22 May 2010 10:46
Ry Nohryb wrote: > On May 22, 3:40 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> > wrote: >> On 22.05.2010 16:10, Ry Nohryb wrote: >> >>> that local vars are >>> not any better than named params, >> Of course they are not (and local vars even worse from the already >> mentioned viewpoint -- they have /two/ assignments (initial - on >> entering, and real - at execution)). >> >> The only lack (and is very inconvenient lack) is that I (analyzing your >> code) should (and we suppose it's more than you small example with 7 >> lines) scroll first to the end (to the call expression) to see, what are >> the values of some strange names "o, where, attr, value" and then go >> back to continue analyze the code -- yes, again scrolling up. >> >> That's it. There is no any other lacks and from the assignments "issue" >> formal parameter for that purpose even win the local vars. > > > function qGen (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; > })(); > } > > aQuery= qGen([], document.body, "width", "100%"); > > >>> that immediate function calls >>> provide a good chance to initialize all of them on the fly using 0 >>> additional lines, >> Yes, that's true. Also there is one important exception when passing via >> formal parameter is needed -- already mentioned by Asen passing /this/ >> value (if you assumes that inside the function context it will have >> other value). > > But that's not any "important exception", afaics, for you can't shadow > "this". Passing it as a parameter just captures it, no matter what it > is, be it the outer this or anything else. > >>> that the var keyword is often superfluous >> It's the matter of taste. So let's leave it for that. Everyone can >> choose his own style. There are pros and cons. And if in case of local >> vars cons are mostly theoretically-technical (/two/ assignments -- who >> cares?), then in case of passing via arguments cons are exact and real >> -- inconvenience for a programmer. >> >> Tacking into account that both name binding will be in the same place (a >> property of an activation object), I prefer to use local vars. But, it >> isn't my rule -- I do so most the time, but also can be a case whey I >> pass them via arguments. Why? Because I just want so and free to do so. > > I usually declare locals as params. LOL. I declare you incomprehensible. > >>> that >>> boolean operators are perfect flow controllers, >> Is it about the topic or this is about something else? Show me an example. > > That instead of if (a) { b() } you can just write a && b(); Yes, in CS such "cute" constructs are known as "job security". In business it is known as being a complete prat who should be shown the door immediately. Hasta la vista El Abuelo! > >>> that it's useless to >>> wrap single-line blocks in braces, >> The same, I didn't get it. Is it relevant or this is from other song? >> And by the way, wrapping a single-line block in braces can also for >> convenience: var a = (bla ? blu : ble). It's just a matter of taste. > > Yes, this parens are useless, where do they come from ? :-) They are useless in that case. But where do you come from? :) |