Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: David Mark on 22 May 2010 14:18 Johannes Baagoe wrote: > David Mark : >> Johannes Baagoe : > >>> perhaps javascript is different, and for a good reason. > >> It is and here's the reason: most JS programmers are incompetent. > > That seems, alas, to be the case. Unfortunately. > >> The trouble is that JS makes it easy for programming novices (or >> even non-programmers) to cobble together something that appears to >> work in their installed browsers. That creates overconfidence, >> which leads to foolhardiness, which leads to all of those errors >> you see in the console. > > Quite, but what can we do about it? Not a thing. That's one point. > Is it better to simply acknowledge > the fact and say "Nothing fancy in production code", or do we attempt > to raise the general level of programming skills even in javascript? How can we do that? > > I'm not suggesting that each and every clever construct should be > endorsed and used, of course. But there is at least one that seemed > very odd when it first appeared, and which has become an indispensable > idiom - Cornford's Construct, `(function() {/*...*/}) ();`. I don't find the one-off construct particularly odd. It fits the language perfectly. > > So, perhaps, there is a case to be made for some ingenuity. I just didn't consider the example code to be ingenuity (more like deliberate obscurity). It wasn't just the use of boolean operators for flow control; the whole thing was a mess. > It could > be argued that so-called "programmers" who can't follow simply aren't > fit to write programs for a living, not even Web applications which > hardly require less skills than, say, business reports in COBOL. Web applications (particularly cross-browser applications) require a lot more discipline than COBOL reporting. > Perhaps that would be a better way to increase the general level of > quality of Web applications than insisting that only what morons can > understand should be used in production code. > It's not so much about understanding as clarity, which leads to ease of maintenance. The fact that it makes it easier for less-disciplined programmers is just a bonus.
From: Dmitry A. Soshnikov on 22 May 2010 14:27 On 22.05.2010 21:55, Johannes Baagoe wrote: > Dmitry A. Soshnikov : >> Johannes Baagoe : > >>> Cornford's Construct, `(function() {/*...*/}) ();`. > >> Why do you call it so? > > I believe that it should have a proper name. By coincidence, a catchy > alliteration is available, like Duff's Device and the Muenchian Method. > >> Did Richard Cornford suggested first to use exactly /this style/ >> of a function expression (with grouping operator) to provide a local >> initializing scope? > > It would seem so. > Well, don't know. The concept of a function expression existed long time before JavaScript (and exactly) in many functional languages. For example, Erlang (which I'm currently diving in): (fun (X) -> 2 * X end)(10). % results 20 The other talk (and purpose) is a private scope, but even from this viewpoint I'm not sure about to whom should be "awarded" the "invention" of the construct (and its exact view -- with a grouping operator) which existed long time before that. Dmitry.
From: David Mark on 22 May 2010 16:25 Ry Nohryb wrote: > On May 22, 5:13 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: >> 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. > > Perfect. > >> 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? > > You've got it perfectly except that you've hardcoded document.body, > "width" and "100%", which in my mind were just regular parameters to a > generic "attribute query generator". (Before David Marks jumps in: That's not my name, George. > I > know that not all html-elements' attributes are reflected in JS-land, > and that those that are, might be with a different name (e.g. class/ > className)) You really don't know what you are talking about, do you? Bugs notwithstanding, all standard attributes of "html-elements" are reflected in "JS-land" in one way or another. So, why wouldn't you want me to "jump in", considering that you seem to be confused about the subject. It's not as if attributes and their related properties are minor details. Misunderstanding their relationship is tantamount to a mathematician misunderstanding basic arithmetic. And since you seem to be asking for it... Why do you think the failings of jQuery (and YUI, Dojo, etc.) in this area are so appalling? These "standard" scripts are supposed to make things easier for beginners. One big selling point is that they have been around for years and used by thousands of developers, who have tirelessly logged bugs, submitted patches, written blogs, etc. This would seem to indicate that they have the basics down pat at this point (roughly five years later). But, as we know, they aren't even close and their authors seem oblivious, even to basic (and often well-documented) problems that date back to last century. If anything, they are making things much harder than they should be. For example, building a CSS selector query engine on top of botched attribute methods is like trying to do calculus with a calculator that can't be counted on to add and subtract correctly. In the same way, creating widgets on top of code that can't measure the height/width of elements consistently is like trying to build skyscrapers with a slightly off tape measure. But I digress. The point is that no other industry would put up with such nonsense. Would you fly in an airplane that relied on Dojo for its instrumentation? How about a space shuttle with rockets controlled by jQuery? For many businesses, Websites are mission-critical. And seeing as JS code is always available for review (unlike the code in Microsoft Windows), there doesn't seem to be any sound reason for such follies to persist. The apologists can wave their hands and point to the fact that lots of people are doing these things, but that doesn't make them any less ill-advised (or the objections to criticism any less ridiculous). > >> 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>) > > LOL. Perl is exceptional. I love this one: > http://99-bottles-of-beer.net/language-perl-737.html > >> Pretty impressive stuff, but perhaps not the most appropriate format for >> production code. There's a time and a place for everything :) > > I too write tricky code is an as clear as possible way, That would seem a contradiction in terms. Why are you trying so hard to be clever when it makes your code less clear? Of course, I know the answer. That's why I fired you. :) > but a little > snippet as that query generator is not exactly "tricky", or is it ? No, it's just less clear than it should be. > > In any case, we ought to do an obfuscated JS contest ! It would be > funny! Not really. I think you'd be happier as a PERL programmer. :)
From: Ry Nohryb on 22 May 2010 17:57 On May 22, 10:25 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Ry Nohryb wrote: > (...) > > (Before David Marks jumps in: > > That's not my name, George. Sorry, a typo. > > I > > know that not all html-elements' attributes are reflected in JS-land, > > and that those that are, might be with a different name (e.g. class/ > > className)) > > You really don't know what you are talking about, do you? Bugs > notwithstanding, all standard attributes of "html-elements" are > reflected in "JS-land" in one way or another. I didn't say *standard* attributes. I said just attributes. If you add the attribute "DavidMark" to an element it won't be reflected in JS- land. > So, why wouldn't you want me to "jump in", considering that you seem to > be confused about the subject. It's not as if attributes and their > related properties are minor details. Misunderstanding their > relationship is tantamount to a mathematician misunderstanding basic > arithmetic. > > And since you seem to be asking for it... I don't agree with you in that matter, you know, so thanks, but no, thanks. With all due respect, not again, please... :-) > (...) > > > I too write tricky code in an as clear as possible way, > > That would seem a contradiction in terms. Why are you trying so hard to > be clever when it makes your code less clear? Of course, I know the > answer. That's why I fired you. :) It's not so much about "trying so hard to be clever" as it's about feeling the joy of using the language to its fullest. What's easy for you you can optimize or write in a compact, pretty, "clever" form from the start, but when you're finding it tricky, when you're still in the struggling phase of solving the problem, still trying to get the algorithm right, when it still doesn't work, you tend to write it as if for dummies and only start thinking about prettifying afterwards, if ever. And I say if ever because there are always some parts of a project that you hate and find boring, and others that you like and enjoy and prettify more. > > but a little > > snippet as that query generator is not exactly "tricky", or is it ? > > No, it's just less clear than it should be. > > > In any case, we ought to do an obfuscated JS contest ! It would be > > funny! > > Not really. I think you'd be happier as a PERL programmer. :) I'd be happier as a Ruby programmer and it's where I'm heading towards right now. -- Jorge.
From: David Mark on 22 May 2010 18:19
Ry Nohryb wrote: > On May 22, 10:25 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Ry Nohryb wrote: >> (...) >>> (Before David Marks jumps in: >> That's not my name, George. > > Sorry, a typo. > >>> I >>> know that not all html-elements' attributes are reflected in JS-land, >>> and that those that are, might be with a different name (e.g. class/ >>> className)) >> You really don't know what you are talking about, do you? Bugs >> notwithstanding, all standard attributes of "html-elements" are >> reflected in "JS-land" in one way or another. > > I didn't say *standard* attributes. I said just attributes. If you add > the attribute "DavidMark" to an element it won't be reflected in JS- > land. I know. That's why I said "standard" attributes. Who cares about non-standard attributes? > >> So, why wouldn't you want me to "jump in", considering that you seem to >> be confused about the subject. It's not as if attributes and their >> related properties are minor details. Misunderstanding their >> relationship is tantamount to a mathematician misunderstanding basic >> arithmetic. >> >> And since you seem to be asking for it... > > I don't agree with you in that matter, you know, so thanks, but no, > thanks. You can put on whatever public face you want, but try arguing with the results I've posted over the years. Beware the black squares. :) And a child could recognize the fallacies I described (and that you snipped). Do you use YUI or jQuery or Dojo? If so, you are either blind or insane. Well, as for the latter; that ship has sailed. Eyesight problems too? > With all due respect, not again, please... :-) It's not for your benefit, George (sorry, typo). This is a public newsgroup. Other people read it. And we know newcomers don't search the archive (even when the GG search feature is working). Get it? > >> (...) >> >>> I too write tricky code in an as clear as possible way, >> That would seem a contradiction in terms. Why are you trying so hard to >> be clever when it makes your code less clear? Of course, I know the >> answer. That's why I fired you. :) > > It's not so much about "trying so hard to be clever" as it's about > feeling the joy of using the language to its fullest. Whatever. From a business standpoint, your joy couldn't be any less relevant. > What's easy for > you you can optimize or write in a compact, pretty, "clever" form from > the start, but when you're finding it tricky, when you're still in the > struggling phase of solving the problem, still trying to get the > algorithm right, when it still doesn't work, you tend to write it as > if for dummies and only start thinking about prettifying afterwards, > if ever. Are you talking about me? > And I say if ever because there are always some parts of a > project that you hate and find boring, and others that you like and > enjoy and prettify more. I do not. > >>> but a little >>> snippet as that query generator is not exactly "tricky", or is it ? >> No, it's just less clear than it should be. >> >>> In any case, we ought to do an obfuscated JS contest ! It would be >>> funny! >> Not really. I think you'd be happier as a PERL programmer. :) > > I'd be happier as a Ruby programmer and it's where I'm heading towards > right now. Good. Why don't you go there. Bye. :) |