[whatwg] Exposing EventTarget to JavaScript

[Alex Russell]

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