- From: Alex Russell <slightlyoff@google.com>
- Date: Mon, 1 Jun 2009 18:02:36 -0700
On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote: > On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell <slightlyoff at google.com> wrote: >> On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >>> Erik Arvidsson wrote: >>>> >>>> To help out with this scenario >>>> it would be good if an implementation of the EventTarget interface >>>> could be exposed to JavaScript. >>> >>> Why do you want the eventTarget interface as opposed to a sane callback >>> function registration setup? >>> >>>> The next and more important step is to allow a JavaScript "class" to >>>> extend an EventTarget. For example: >>>> >>>> function MyClass() { >>>> ?EventTarget.call(this); >>>> ?... >>>> } >>>> MyClass.prototype = new EventTarget; // *[1] >>> >>> So this already works, no? >>> >>>> One more thing needs to be mentioned and that is how event propagation >>>> should work in scenario. If the object has a "parentNode" property >>>> then the event dispatching mechanism will do the right thing. >>> >>> What, precisely, is the use case for this in general? ?In the DOM, >>> propagating events to parents makes sense (esp. because parents are unique). >>> ?What would be the use case in a general object graph? >> >> Most of the JS object graphs that you'll see in the wild either >> represent data hierarchies (wherein updates might trigger a UI change) >> or wrapped sets of DOM nodes as a way to make up for the fact that you >> can't freaking subclass Element from JS. In the latter case, it's >> natural to need it to keep up the facade. In the former, it's a >> performance convenience. >> > > If I understand you correctly, you want to subclass the Element interface. Think bigger. I want to create a concrete Element class (that's what a <span> is, for all intents and purposes), re-interpret all the other elements in the DOM "class hierarchy" in terms of it, and make it subclassable (or treat it as a Trait for purposes of composition) so that we can do a component system that lets you introduce new elements that act sanely both in the HTML and JavaScript senses. > If I got that right, then I am not sure how that concept would relate, > as there are not interfaces in javascript, and so I am not sure how an > object that has the interface of Element could also have the interface > of your subclass. In the could have been ES4, maybe, but that is > would-be fiction now. > > I can't think of any reason that anyone would even want that, anyway. > In a fictitious version of javascript where interfaces could be > created, you could just create your own, then implement both in the > target class. > > But in reality, you could do something retarded like try to subclass > NodeList. Oh yeah, someone already tried that, didn't they? ...wow. Not sure I should engage with the rest of your message. It's belligerent for no apparent reason. Regards
Received on Monday, 1 June 2009 18:02:36 UTC