From: Asen Bozhilov on 14 Jun 2010 16:14 Garrett Smith wrote: > Richard Cornford wrote: > > Asen Bozhilov wrote: > >> for (var i = 0, len = coll.length; i< len; i++) { > >> coll[i].onclick = function () { > >> //.... > >> }.bind(thisValue); > > >> } > > >> And by ECMA-262 should be created `len' * 2 objects. > > > There is no need to wait for the future, I have already seen code > > exactly like that. > > I see it too. > > The approach given is inefficient and clumsy. Beginners want to do this > to fix variable this arg but it's not necessary. > > A better solution for what the above code appears to be doing would be > to register an event handler -- just one -- on a common ancestor and use > delegation. > > // Typical approach using delegation. > container.onclick = function(ev) { > var target = getTarget(ev); > if(isPanelActuator(target)) { > panelActuatorClickHandler(target, ev); > } > > } Yes, that approach is better than registration handler for each element. For example I use similar code in Firefox extension which should handle user clicks on pages in opened tabs. So my code looks: var content = document.getElementById('content'); content.addEventListener('click', handleClick, true); May be FAQ should noticed about that approach. Here are many threads in which that approach is posted, especially Thomas Lahn has posted many times.
From: Dmitry A. Soshnikov on 14 Jun 2010 16:46 On 14.06.2010 19:24, Richard Cornford wrote: > On Jun 14, 3:03 pm, Dmitry A. Soshnikov wrote: >> On 14.06.2010 17:46, Asen Bozhilov wrote: > <snip> >>> ... . Would you want implementations to follow that or they will >>> make optimizations behind the scene and behind the ECMA-262 >>> standard? >> >> By the way, I see that "joined objects" are gone from the ES5 too. > > Some years ago some of the participants in this group put quite a lot > of effort into trying to find evidence for "joined objects" in > javascript implementations, with zero success. So probably the only > thing that is lost by their being removed from ES5 is the possibility. > Yep, it's quit strange thing, even if the [[Scope]] property is indistinguishable. Because of again -- joined objects should copy non-internal properties bidirectionally (similar to the case with mentioned Asen's proposal for "bind"): function A() { function B(x) {return x*x;} return B; } var b1 = A(); var b2 = A(); b1.foo = "bar"; alert(b2.foo); // should be "bar" if objects are joined alert(b1 === b2); should be true I remember one discussion (but can't find it now, if you'll find, let me know) where joined objects are recognized as not so needed, so I guess they were removed from ES5 because of that. Dmitry.
From: Dmitry A. Soshnikov on 14 Jun 2010 16:48 On 14.06.2010 14:46, Dmitry A. Soshnikov wrote: <snip> > > (2) it's not possible to implement the spec's behavior in JavaScript of > the `new` bound functions Yes, it's possible: <URL: http://bit.ly/aboVXU> -- implemented by Bozhilov; I've updated the article. Dmitry.
From: Garrett Smith on 14 Jun 2010 19:49 On 6/14/2010 1:14 PM, Asen Bozhilov wrote: > Garrett Smith wrote: >> Richard Cornford wrote: >>> Asen Bozhilov wrote: > [...] > May be FAQ should noticed about that approach. Here are many threads > in which that approach is posted, especially Thomas Lahn has posted > many times. > That would be a really good idea. The subject comes up enough. An event delegation entry and an execution context entry would both be useful. The execution context entry might be worded as: What does the "this" keyword refer to in a function call? It is mentioned in the code guidelines doc in three places: http://jibbering.com/faq/notes/code-guidelines/#design | Do not traverse over elements to modify the style or add an event | callback to each element. and below that: | For events, use event delegation. That is, replace a loop that adds a | callback to each element in a collection with a callback on a common | ancestor. Garrett
From: pedz on 14 Jun 2010 22:08
On Jun 14, 6:49 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > It is mentioned in the code guidelines doc in three places: > > http://jibbering.com/faq/notes/code-guidelines/#design I was curious so I poked the link. The first bullet was not clear to me. Why is: > goog.isDef = function(val) { > return val !== undefined; > }; a useless function? Also, reading a little further, the term "nonstandard" might be avoided. The function statement, it says, is "nonstandard" but it is in the 3 and 5 standards. The key point is that it is "allowed" and not "required" and it is that choice of the implementers that make it a bad choice to use. Calling something in the standards a nonstandard isn't helping the unenlightened. |