Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: Johannes Baagoe on 22 May 2010 10:53 David Mark : > Yes, in CS such "cute" constructs are known as "job security". Not in CS, in IT, which is quite different. Both are important, neither should dismiss the other's concerns. After all, they both benefit a lot one from another. -- Johannes
From: Dmitry A. Soshnikov on 22 May 2010 11:09 On 22.05.2010 18:26, 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%"); > I don't understand the goal of what you're trying to show me. I understand, you're saying something like: "look, it's the same if I declare function first and the call it" -- but that's irrelevant with the case. You was talking about some "useless additional line" provided by the local "var" and then show me the same additional line by calling the function after its definition. What's the goal of your writing? Are you trying to prove me something or to say that passing via arguments (in /concrete relevant case/ -- immediate invocation of an FE) is better? I thought we've already decided that this is the matter of taste and describe pros and cons of both variants. Or I missed something? > >> >>> 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", For me, it is. > afaics, for you can't shadow > "this". What do you mean, shadow /this/ ? I don't wanna shadow /this/, I just want to get /this/ value of the caller in a view of a formal parameter. > Passing it as a parameter just captures it, no matter what it > is, be it the outer this or anything else. > That exactly I want, and nothing 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's your choice, you're free in it, nobody says that it's worse. I just said that it will be inconvenient for me to scroll down first, and then scroll up back. That's it. There is no need to show some alternative examples with separating definition and execution of a function, I understand the goal and see pros and cons. >>> 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, I like it also in some cases (mostly, when conditions is simple -- with one-two predicates). If condition is more complex, I prefer /if/. >>> 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 ? :-) > The definition of a "uselessness" is just in your head and depends on your habit and taste. Let's say correctly: (1) it isn't required, but (2) everyone can use it if it is convenient for him, e.g. to group (with a /grouping/ operator, notice) some logical parts. Personally, I again can use both cases and think that it isn't worth to talk about it on 10 pages ;) Dmitry.
From: David Mark on 22 May 2010 11:12 Johannes Baagoe wrote: > David Mark : > >> Yes, in CS such "cute" constructs are known as "job security". > > Not in CS, in IT, which is quite different. Well, I first heard it from a CS professor. He was describing a very obtuse construct, not unlike El Abuelo's examples. > Both are important, neither > should dismiss the other's concerns. Who's dismissing? > After all, they both benefit a lot > one from another. > Yes. And neither benefits from bad code.
From: Stefan Weiss on 22 May 2010 11:13 On 22/05/10 16:22, Johannes Baagoe wrote: > 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. Count me in as an average programmer, then. In order to understand the example, I had to rewrite it and rename the variables/arguments: aQuery = (function () { var list = []; list.refresh= function () { var set = document.body.getElementsByTagName('*'), i = set.length; list.length = 0; while (i--) { if (set[i].width === "100%") { list[list.length] = set[i]; } } return list; }; list.refresh(); return list; })(); Unless I made a mistake during refactoring - which is entirely possible, I didn't test it or spend a lot of time on it - aQuery is a sparse array of all elements in the body with a "width" property of "100%". It also has a refresh() method which will update the array and return the aQuery object for method chaining. The "width" property looks suspicious. Not necessarily a bug, and it could be intentional, but I wonder how easy it is to find such problems in a "compressed" piece of code? I enjoy playing around with terse and obfuscated code, too. For example, this is a working Perl program, written entirely with keywords: not exp log srand xor s qq qx xor s x x length uc ord and print chr ord for qw q join use sub tied qx xor eval xor print qq q q xor int eval lc q m cos and print chr ord for qw y abs ne open tied hex exp ref y m xor scalar srand print qq q q xor int eval lc qq y sqrt cos and print chr ord for qw x printf each return local x y or print qq s s and eval q s undef or oct xor time xor ref print chr int ord lc foreach qw y hex alarm chdir kill exec return y s gt sin sort split (from <http://www.perlmonks.org/index.pl?node_id=290607>) Pretty impressive stuff, but perhaps not the most appropriate format for production code. There's a time and a place for everything :) -- stefan
From: Johannes Baagoe on 22 May 2010 11:29
Stefan Weiss : > Pretty impressive stuff, but perhaps not the most appropriate format for > production code. There's a time and a place for everything Exactly. I find Ry Nohryb's cute constructs both entertaining and to some extent enlightening - in general, not this particular snippet. I don't know whether they could or should make their way into production code. What is considered too obscure seems to depend on the language. Nobody would hire a Perl programmer who didn't understand open(IN, $file) or die "Couldn't open $file - $!\n"; but perhaps javascript is different, and for a good reason. -- Johannes |