Using "new function() {...}" as a Singleton
in [JavaScript]
|
From: Ry Nohryb on 25 May 2010 06:25 On May 25, 2:44 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > (...) > Did Jorge use that definition? Or did he communicate in a vague way and > you elaborated on it? (...) OMG, you can't even read ? -- Jorge.
From: Eric Bednarz on 25 May 2010 11:34 Garrett Smith <dhtmlkitchen(a)gmail.com> writes: > Eric Bednarz wrote: >> Scott Sauyet <scott.sauyet(a)gmail.com> writes: >> >>> I'm pretty sure posters here had some reasonable critiques of using >>> this style to declare a singleton: >> >> I'm pretty sure I would like to know how and more than all why one would >> try to implement the singleton pattern in a class-free language. >> > > That type of pattern allows an object to have private scope. I understand that, but I still don't understand what a singleton is in a class-free language, and why anybody would want one. :-) -- λ
From: Garrett Smith on 30 May 2010 02:05 On 5/25/2010 4:09 AM, David Mark wrote: > Garrett Smith wrote: >> On 5/24/2010 6:57 PM, David Mark wrote: >>> Garrett Smith wrote: >>>> On 5/24/2010 2:11 PM, 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 : >>>>>> >>>>>> [...] [...] >> >> But jQuery might be selecting that element, depending on the browser, >> its version, the rendering mode, and other css rules. The article says >> that jQuery finds the elements whose "width is 600px". > > They have no idea what they are doing. That's not news. But I checked > their latest and they don't even call their own "attr" function in the > query portion, so the height/width thing I was referring to does not > apply. Apparently you meant that their docs were wrong. That's not > news either. > Apparently I was referring to an article that the jQuery team tweeted about. I've stated that several times now. Get with the picture. > >> >> Attributes describe the element, styles describe its appearance. >> >> Recent browsers that implement getComputedStyle will return a computed >> style width, based on apparently a nonstandard algorithm. This is >> probably as a consequence of developers wanting that value and filing >> invalid bugs. > > That's why you should use my patented avoidance technique. > > http://www.cinsoft.net/size.html > That one's obviously no good. If you'd tested it you would probably have realized that. > Positions too: > > http://www.cinsoft.net/position.html > Where are the unit tests? >> >> So, if that element is matched in the author's selector query >> "img[width=600]" the query would not be doing what he says it does. >> Namely, it would not match "all the images whose width is 600px". > > Yes, it's all nonsense. Don't rely on these silly query engines (or > their documentation). > > http://www.cinsoft.net/slickspeed.html > Pass on that. >> >> That expectation is based on observations of design bug of jQuery and >> even at that, the query will fail, matching an element whose display is >> "none" in those recent browsers that implement getComputedStyle. In IE8 >> and below, it will not match the element, and so it will do what the >> author says it does. > > I think you are a bit confused about how jQuery's Sizzle thing works. > [...] Are you bluffing? What jQuery does for attribute selectors is inconsistent with the CSS 2.1-based Selectors API (draft). jQuery results are inconsistent and depend on the element, its applied style values, the browser, its version, the rendering mode, whether or not attributes are quoted, whether or not the "context" param is present. jQuery wraps QSA in try catch that will often, depending on the code, result in the catch block being entered. At that point the hand-rolled query engine is used. Throwing errors is a performance hit, and one which I would certainly want to avoid, however considering the other inefficiencies in jQuery, I could see how this could seem insignificant to the author(s). The author of that article stated that the attribute selectors provide a "very accurate" way to "select the elements knowing their attributes and values". The examples he provided have a comment that contradicts what he says it does in the article; that: "img[width=600]" matches "all the images whose width is 600px". That selector will do that in certain cases and in certain browsers, but not consistently across the browsers that are supported. What the comment says sure doesn't match anything close to native Selector API (and the query itself is invalid anyway). Sizzle matches nodes based on the DOM that the browser builds. The DOM varies, especially in various versions IE. Trying to accommodate for those shortcomings is, as I stated earlier, not outweighed by the complexity entailed by that. Results depending on the selector text used, quotes on attribute values, the presence of a `context` arg (second param for jQuery(selector, context)), can have a result that seems paradoxical, like a "Shroedinger's Cat" result. [...] >> >> You too validated the concept by publishing a library yourself, copying >> the idea, and proclaiming it to be superior and with no unit tests, too >> boot! > > Are you being silly? I've always said the (completely optional) query > portion was basically a parody and should not be used. And the > comparisons between mine and the products of the "many eyes" projects > are quite illuminating. As was well documented last winter, it didn't > take more than a few weekends to accomplish what they have failed to do > in five years. You better believe it is superior (in virtually every > way possible). So if you must, you best use mine. > YOu wanna know what's silly? Designing an API "to make a mockery of jQuery". Worse yet, providing an interface with methods "E" and "Q" and whatever the other one-letter method names are, along with other badly named abstractions that provide value, such as gEBI or getEBI, etc. Just use the real method: document.getElementById. All this, while claiming to be superior. Where are those unit tests you keep mentioning, BTW? > And I do have unit tests, not to mention the most extensive query tests > in the business (which are essentially unit tests themselves). > .... >> >> [...] >> >>> >>>> >>>> By the way, CSS2.1 states that attribute selectors take a string >>>> (quoted) or identifier, as in img[width="600"], and not img[width=600], >>>> but provided examples showing unquoted values as strings. >>> >>> That's the least of their worries. >> I think you are a bit confused about how jQuery's Sizzle thing works. >> Yep. It's a separate issue and probably going to be more of an issue for >> the WG to contend with, as people are used to attribute selectors >> working without quotes. > > Now that QSA is here, using a two-level QSA with a side of mish-mash > library is beyond ludicrous. Of course QSA behaves very differently > than the handmade query engines, which are demonstrably incomplete and You don't say? So was there something to attribute selectors being unquoted after all? > full of bugs. What the hell are people thinking using something like > "Sizzle" as a fallback? What the hell were the authors of these things > thinking providing such "solutions"; oh wait, they were thinking they > better bottle something quick as their only idea had been taken over by > the browsers. > Using QSA might make sense in the near future, depending on how widely it is implemented. It is incompatible with the libraries today. As to what "they" are thinking, you can either guess or assume. You could, for example ask: | What is the rationale for using Sizzle as a fallback when QSA is | unsupported? Are you aware that the two are incompatible? You could start a new thread on that and even post a link from jQuery forums (or tweet or blog, etc). Keep in mind that if you call names and insults, it becomes a lot easier to dismiss your criticism as biased hate. Garrett
From: Garrett Smith on 30 May 2010 03:07 On 5/29/2010 11:05 PM, Garrett Smith wrote: > On 5/25/2010 4:09 AM, David Mark wrote: >> Garrett Smith wrote: >>> On 5/24/2010 6:57 PM, David Mark wrote: >>>> Garrett Smith wrote: >>>>> On 5/24/2010 2:11 PM, 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 : >>>>>>> >>>>>>> [...] > [...] >> http://www.cinsoft.net/size.html >> > > That one's obviously no good. If you'd tested it you would probably have > realized that. > I meant the following (position) is no good. The previous one (size) looks OK. >> Positions too: >> >> http://www.cinsoft.net/position.html >> > > Where are the unit tests? > Garrett
From: David Mark on 30 May 2010 11:53
On May 30, 3:07 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 5/29/2010 11:05 PM, Garrett Smith wrote: > > > On 5/25/2010 4:09 AM, David Mark wrote: > >> Garrett Smith wrote: > >>> On 5/24/2010 6:57 PM, David Mark wrote: > >>>> Garrett Smith wrote: > >>>>> On 5/24/2010 2:11 PM, 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 : > > >>>>>>> [...] > > [...] > > >>http://www.cinsoft.net/size.html > > > That one's obviously no good. If you'd tested it you would probably have > > realized that. > > I meant the following (position) is no good. The previous one (size) > looks OK. OK?! Quirks mode, standards mode, any units, box-model variations, etc. It's a rock. Compare and contrast to jQuery's nonsense (as cited in the page). > > >> Positions too: > > >>http://www.cinsoft.net/position.html > > > Where are the unit tests? > Unit tests for a test page? And I tested it to death in a heart- stopping number of browsers. I did far more tests than are demonstrated on the page, including fixed positioning and elements positioned with only a single rule (e.g. right). Perhaps you don't understand the concept? It is designed to retrieve a pair (e.g. left/top, right/bottom, right/top, etc.) The caller must know which pair they are interested in. For example, given an element positioned like this:- #myelement { top:20px; } ....the test function will dutifully fill in two of the three "blanks" (left and right). Obviously you can't use both of them together. In this case, you could make use of the top/left or top/ right pairs. My plan is to eventually replace the more complex getElementPositionStyle function in My Library (which is limited to figuring left/top) with this version. For that, I will add an argument for the caller to specify which pair they want and it will return null if that pair cannot be determined. Get it? Beats the hell out of relying on getComputedStyle and the like (for many reasons which we discussed to death just a month or so ago). |