Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: Stefan Weiss on 22 May 2010 11:29 On 22/05/10 16:46, David Mark wrote: > 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 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. This style of flow control is perfectly normal in other languages. It's used extensively in shell scripts and Perl scripts, for example (and many others, I'm sure). For example, nobody would blink an eye about these uses: # in a bash script test -r ~/.bashrc && . ~/.bashrc # in a Perl script $user->isAdmin() or die "Access denied.\n"; It's not so common in OO languages, where the preferred style is usually more verbose. Speaking only for myself, I tend to follow the conventions of the language I'm currently using. -- stefan
From: David Mark on 22 May 2010 11:40 Stefan Weiss 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. > > 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? Not very. :) > > 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 Dear God. PERL programmers drive me nuts.
From: Ry Nohryb on 22 May 2010 11:45 On May 22, 4:46 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > 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: > > > I usually declare locals as params. > > LOL. I declare you incomprehensible. Well, s/usually/often > >>> 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. Q: Objectively, what's wrong with a && b(); ? A: Nothing. > Hasta la vista El Abuelo! Ja, qué salao! > >>> 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? :) I might come from "un lugar de la Mancha de cuyo nombre no quiero acordarme" :-) -- Jorge.
From: David Mark on 22 May 2010 11:52 Ry Nohryb wrote: > On May 22, 4:46 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> 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: >>> I usually declare locals as params. >> LOL. I declare you incomprehensible. > > Well, s/usually/often Groan. That was the one word (over two letters long) that made sense. :( > >>>>> 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. > > Q: Objectively, what's wrong with a && b(); ? > A: Nothing. > >> Hasta la vista El Abuelo! > > Ja, qu� salao! Klaatu barada nikto! > >>>>> 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? :) > > I might come from "un lugar de la Mancha de cuyo nombre no quiero > acordarme" :-) Why don't you go back there? :)
From: Dmitry A. Soshnikov on 22 May 2010 11:58
On 22.05.2010 18:22, Johannes Baagoe wrote: > Dmitry A. Soshnikov : > >> Is it relevant or this is from other song? > > Ry Nohryb likes cute constructs that > minimise code lines. I like them too. And always (try to) write as effective by a /code reuse/ and short code elegant constructions as possible. The only reason, when I prefer other way is when it seems less convenient for me. That's it. > Most other contributors frown upon anything the > average programmer may fail to understand and maintain. This reason I always don't like as an logical argument in talks (it's not about you, it's in general). The situation is simple: some (authority) having a previous experience in /other/ language writes a book, describing e.g. things like /a && b();/ as (let suppose) "bad practice", arguing that for some programmers it is hard to understand and isn't habitual. Of course, the readability matters. And the clear readable code reason is on the first place. But. We should talk about the concrete exact language and its constructions which are specially was invented as alternative for that long boding (invented /before/) constructions. That logical chains such as /a && b();/ there are in many languages: ECMAScript, Ruby, Python, Erlang, etc. and I use such constructions very often (regardless that someone can tell me: "can you use /if/ instead? Because it isn't habitual for me after <previous language>"). It also depends of the professional level of a programmer. It's like e.g. math: there is a technical school math, there is an university school math, there is an academical level math... etc. So why the hack from this position I should use "beginners secondary school math" constructions for the reason that my code can be understood by any newbie after reading "JavaScript for dummies"? So, personally I have the following priorities of a code: 1. Readability (by your own wish level, but not forced by some meaning that "this will be non-habitual for C-programmers"); 2. All other invented (specially invented to improve code reuse stylistics) constructions which can decrease readability, but can improve (a) code reuse and make such constructions more elegant/less to write, (b) performance. So, for any middle/professional level ES/Ruby/Python/Erlang/etc. programmer the constructions such as: a && b(); a = a || b; etc. should be /absolutely normal/. Dmitry. |