Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: Johannes Baagoe on 23 May 2010 17:31 Dmitry A. Soshnikov : > How are /you/ relevant (and /your/ knowledge) with theoretical > invention made much earlier? I don't think it matters much, but I do have some notions of the history of programming languages. > 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. Of course. I don't want to suggest that Crockford or Cornford or any known, specific other person actually *invented* the construct. No more than I would like to claim that Columbus invented the egg. As Conford quite rightly points out, "It could be argued that Brendan Eich must have 'invented' it, as it was an inherent possibility in the language from the moment function expressions were introduced." > objectively, they are not inventors. Although, helped to spread > and show some useful conceptions /applied to JavaScript/. No more, > no less. Exactly. No more, no less. > 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. To sum up: we haven't found a good and fitting expression. I am quite ready to abandon my proposal if it risks to start a war, Cornford himself quite properly doesn't advocate it. What I *would* like, though, is that we find and agree on a short and catchy name. I don't want to have to say or write "anonymous function expression which is being executed immediately after its creation" or even "immediately invoked function" hundred times during an introductory course on javascript. > What does CS abbreviation mean? "Computer science". -- Johannes
From: Dmitry A. Soshnikov on 24 May 2010 04:48 On 24.05.2010 1:31, Johannes Baagoe wrote: > Dmitry A. Soshnikov : > >> How are /you/ relevant (and /your/ knowledge) with theoretical >> invention made much earlier? > > I don't think it matters much, but I do have some notions of the > history of programming languages. > Excuse my, maybe a bit rude formed, sentence, but I meant that there are things that exist without our knowing about them and without our emotional feelings to them. That exactly I meant, -- not (your) "knowledge", but your (my, our) "knowing" of something (i.e. to be informed). > As Conford quite rightly points out, "It could be argued that Brendan > Eich must have 'invented' it, as it was an inherent possibility in > the language from the moment function expressions were introduced." > Yes, but Brendan Eich just borrowed this ideology (and I like it) to the language; i.e. even he didn't invent it. > What I *would* > like, though, is that we find and agree on a short and catchy name. Yes, then we can continue researches ;) >> What does CS abbreviation mean? > > "Computer science". > Ah, thanks (I of course know what is "Computer science" but haven't heard often "CS" abbreviation). Dmitry.
From: Garrett Smith on 24 May 2010 16:20 On 5/22/2010 1:25 PM, David Mark wrote: > 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 : [...] > 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. > [...] You've qualified the term "reflect" with your own "in one way or another". The concept of "reflects" is explained in HTML 5 draft. We've discussed this before. A content attribute that "reflects" has its current value represented by a dom property. Not all content attributes reflect. http://www.w3.org/TR/html5/infrastructure.html#common-dom-interfaces You mentioned that jQuery conflates properties and atttributes; however they also conflate computed styles with conflation. Thus, in jQuery, the selector: *[width=600] - may (incorrectly) select: <img class="logo"> - depending on the browser, its version, and the rendering mode (or document mode). The jQuery team seems to either be unaware of this problem or in denial of its existence, as evidenced by recent promotion of the following tutorial: | Some Good and Advanced jQuery Techniques - http://bit.ly/dli5EN | 9:01 AM May 9th via TweetDeck I can understand that there are problems that they won't fix but I cannot see why they would advocate something that is obviously incorrect. Either they are unaware of the problem (though that seems impossible at this point) or they are aware of it and ignore it.
From: David Mark on 24 May 2010 21:42 David Mark wrote: > Garrett Smith wrote: >> On 5/22/2010 1:25 PM, David Mark wrote: >>> 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 : >> [...] >>> 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. >>> >> [...] >> >> You've qualified the term "reflect" with your own "in one way or another". > > Meaning that they are abstracted in some way (e.g. the "style" attribute > is reflected as an object). > >> The concept of "reflects" is explained in HTML 5 draft. > > There you go again. How are the contents of that draft possibly > relevant to this discussion? > >> We've discussed >> this before. A content attribute that "reflects" has its current value >> represented by a dom property. Not all content attributes reflect. > > Name a (standard) one that doesn't. Time. It was a trick question as there isn't one. If there was, this demonstration would have been impossible:- http://www.cinsoft.net/attributes.html ....as IE < 8 (and Compatibility View) have no proper attribute methods (e.g. get/setAttribute). Yet, the example script emulates them by referring exclusively to reflected property values. And yes, it even works for properties that hold user input. For example, the value attribute is reflected in the defaultValue property, checked in defaultChecked, etc. I'm sure this information is in some (real) specification somewhere; and if it isn't, the specification is out of whack with reality. Furthermore, these critical (and basic) details were never reflected in the logic of any "major" library or framework. Clearly the neophytes who wrote them bit off far more than they could chew with CSS selector query engines as they don't yet know how to read documents. These aren't newly discovered wrinkles. The rules were firmly in place long before the first line of Prototype was written. Five years later, the authors of jQuery, Prototype, Dojo, YUI, etc. are no closer to solving these "mysteries". Why? Because you can't learn anything using the peer-patch-and-pray approach to programming. I've personally handed the answers to the owners of two of those four projects. The response was the usual "show me where it fails!" In Dojo's case, I tried to do that, but first needed them to define what their (roughly 15-line) "attr" method was supposed to do. The design appeared to be quite random; and, after all, you have to know the expected outcome to demonstrate a failure. Their testily given response was that I should look at the results in FF as those were "right". In other words, it works how it works. Told that that was a circular definition, they starting whining about "ad hominem" attacks and calling for me to be banned from their developer mailing list. And not long after they installed a moderator so they could "get back to having fun again". :) I stopped posting as a result and, last I checked, they were still lost in space (but having lots of fun I guess). You aren't going to write Shakespeare if you can't read comic books. If you a calculator says 1 + 1 = 3, don't use it to do your taxes. If a yardstick measures a meter... Well, do I really need to go on? Cue the apologists... :)
From: Garrett Smith on 25 May 2010 02:25
On 5/22/2010 8:09 AM, Dmitry A. Soshnikov wrote: > 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)). >>> So what? Is that a performance trick? For all you know, evaluating an ArgumentList might be a greater performance hit in any one browser. With no parameters, there would be no reason to have an argument list, so that evaluation step would be avoided. Regardless, the amount of CPU wasted on evaluating simple assignment to local variables is generally very very fast and is only measurable in the most extreme cases. Providing the initial undefined to variables is also very simple for the interpreter and is of course very very fast. >>> 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. >>> Even if you don't scroll, you have to look twice; basically reparsing. If the variables are assigned at the top of the function; it can be read from top to bottom. > > 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. > Agreed. Having the variables assigned at the bottom comes at a cost of readability. It saves the use of the keyword `var` but that is hardly much of a benefit and the performance boost of using parameters seems like . The cost is readability; you have to scroll down to see the local variables. |