Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: David Mark on 23 May 2010 14:50 Dmitry A. Soshnikov wrote: > On 23.05.2010 21:18, Ry Nohryb wrote: >> On May 22, 7:02 pm, Johannes Baagoe<baa...(a)baagoe.com> wrote: >>> (...) 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() {/*...*/}) ();`. >> >> Maybe, at the very best, the [name both of them] construct, because >> there's no doubt that it's been Douglas Crockford who has contributed >> more than anybody else to its divulgation. Not Cornford nor c.l.js >> neither its FAQ. > > Again, I don't understand, why the construct which existed long time > before JavaScript should be named by Crockford's or Cornford's names? > They both not relate to function expressions and their particular view > -- with a grouping operator. Yes, maybe /you/ learned it from > Crockford's video, but before it this construction (and that is much > more essential -- ideology -- of a function literal, which can be > created dynamically, passed as a funarg, or e.g. executed right after > its creation) happily existed. > > So, the name is (my proposal): "An immediately invoked function" > (without specifying even that this is an expression, because it goes > without saying). > >> >> I've witnessed for the last 3+ years the influence of this group and >> it's ~= nil, what a waste, what a lost opportunity, not to mention the >> fact that the few (JS newbies or not) that every now and then happen >> to dare to post here asking for help or advice more often than not are >> immediately repelled by the harsh + impertinent answers of no help nor >> valuable advice by the usual bunch of bigoted regulars. >> > > Yes, unfortunately that's true. It certainly is not. > But everything can be changed. You can > also start to do it. The first step (as I see) -- do not start > irrelevant discussions which turn then to useless flame and holy wars. A > classical example: some newbie asks question about inheritance and shows > a code (about 10-20 lines). In one line some finds /alert(...)/ -- and > that's it -- nobody already remember from what the discussion was > started -- everyone now discussed on 10 pages that should be (haha) > /window.alert/ ;) You are dreaming.
From: SteveYoungTbird on 23 May 2010 15:54 David Mark wrote: > Ry Nohryb wrote: >>> On May 22, 7:02 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: >>> what a waste, what a lost opportunity, not to mention the >>> fact that the few (JS newbies or not) that every now and then happen >>> to dare to post here asking for help or advice more often than not are >>> immediately repelled by the harsh + impertinent answers of no help nor >>> valuable advice by the usual bunch of bigoted regulars. > > That's a nonsensical over-generalization that you are in no position to > make. And it sounds suspiciously like parroting to me (as I've > certainly heard this before). I'll bet you have! <snip>
From: Johannes Baagoe on 23 May 2010 16:19 Dmitry A. Soshnikov : > The concept of a function expression existed long time > before JavaScript (and exactly) in many functional languages. Of course, but not in any previous "mainstream" language I know. > 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. The point is that in javascript, you *need* such a construct much more often than elsewhere. 1. Because the scope of identifiers is a function, not a block. So, you may have to write (function() { for (var i = 0; i < 1000000; i++) { /* do something */ } })(); merely to be sure that your `i` is not going to overwrite an important global some fool named "i" somewhere in a big mess of code. 2. Because what other languages call "static" variables have to be implemented in closures. And therefore, what was a cute exotic curiosity only used by CS majors became a basic tool any beginning javascript programmer has to learn. -- Johannes
From: Dmitry A. Soshnikov on 23 May 2010 16:57 On 24.05.2010 0:19, Johannes Baagoe wrote: > Dmitry A. Soshnikov : > >> The concept of a function expression existed long time >> before JavaScript (and exactly) in many functional languages. > > Of course, but not in any previous "mainstream" language I know. > How are /you/ relevant (and /your/ knowledge) with theoretical invention made much earlier? Yes, "mainstream" matters (in some degree), but let us don't call as "inventors" those who just explain you that theoretical facts which existed not even before Crockford's videos, but long time before JavaScript itself. If you want you may name some person as your teacher which helped you to understand some topic and enlighten you. But objectively, they are not inventors. Although, helped to spread and show some useful conceptions /applied to JavaScript/. No more, no less. Regarding ECMAScript, its specification has exact definition of a function expression. From the general theory, a function literal (i.e. a first-class function object) completely corresponds to that definition from the ECMA-262-3(5) specification. And nothing prevents to execute this function object right after its creation -- if you want, I can show the same examples in other languages -- in Python (from which ECMAScript took much ideas), Ruby, Erlang again, other. So, it can be named as "(anonymous) FE which is being executed after its creation" or for shortness (I let myself to repeat) -- "an immediately invoked function". Thus, word "immediately" relates to "right after the creation". Crockford uses "immediate function" -- yeah, for shortness it matches, but maybe doesn't concentrate attention of exactly "invocation". I've heard "self-executing" function and think that it isn't fit because "self-executing" is relates to a recursive function. >> 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. > > The point is that in javascript, you *need* such a construct much more > often than elsewhere. > > 1. Because the scope of identifiers is a function, not a block. So, > you may have to write > > (function() { > for (var i = 0; i< 1000000; i++) { > /* do something */ > } > })(); > > merely to be sure that your `i` is not going to overwrite an important > global some fool named "i" somewhere in a big mess of code. > Absolutely the same semantics there is in other languages. The same again Python from which ES took much. It isn't the fact to say that some person "invented" that idea for you. "Explained", "enlighten" -- repeat, maybe, but not "invented". > 2. Because what other languages call "static" variables have to be > implemented in closures. > Also the same, a "static" concept varies in some languages, and I can show you an example again in the same Python with the same semantics. > And therefore, what was a cute exotic curiosity only used by CS majors > became a basic tool any beginning javascript programmer has to learn. > What does CS abbreviation mean? Dmitry.
From: David Mark on 23 May 2010 17:17
SteveYoungTbird wrote: > David Mark wrote: >> Ry Nohryb wrote: >>>> On May 22, 7:02 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > >>>> what a waste, what a lost opportunity, not to mention the >>>> fact that the few (JS newbies or not) that every now and then happen >>>> to dare to post here asking for help or advice more often than not are >>>> immediately repelled by the harsh + impertinent answers of no help nor >>>> valuable advice by the usual bunch of bigoted regulars. >> >> That's a nonsensical over-generalization that you are in no position to >> make. And it sounds suspiciously like parroting to me (as I've >> certainly heard this before). > > I'll bet you have! > As has everybody who reads this group, genius. |