Re: addEventListener naming

On Thu, Aug 27, 2009 at 1:10 AM, Alex Russell <slightlyoff@google.com> wrote:
>>> The bigger challenge will be in getting the ES WG to accept a native
>>> listen() method for all JavaScript objects. Having a listen() method
>>> in the DOM is only half of the solution: getting to an integrated
>>> development environment means that we should also be able to expose
>>> the exact same API for methods on regular JS objects.
>>
>> By "ES WG", I take it you mean TC39?  This would be a DOM method; I don't
>> think there is any particular coordination needed with ECMA on this (unless
>> I'm missing something).  This would not be on all JS objects, right, just
>> EventTargets?
>
> Nope, I'd like to propose that a listen() method be added to ALL
> objects in JS. The goal here is to unify JS and DOM behavior.
> Hierarchy, bubbling, etc. probably don't apply in the non-DOM case,
> but one could image an interface that objects could implement (say,
> and eventParent property) to delegate dispatch "up" the chain.
>
> Regardless, it's crazy that we have one way of thinking about "events"
> in DOM (a terrible, Java/C++-centric API) and one way of thinking
> about events in JS (ad-hoc AOP-style systems and monkey-patching).

Note that JS objects generally don't have a reference to their
"parent". So it would be prohibitively costly to traverse up the
"parent chain" in order to fire events.

Also note that JS objects don't generally form a tree, but rather an
arbitrary graph. So the concept of "parent" doesn't even need to
exist. For example, what would you do if you were to dispatch an event
on the 'x' object below:

x = { hello: 'world' };
a = { child: x };
x.child = a;
b = { child: x };

Here both 'a' and 'b' are "parents" of 'x'. And 'x' is a parent of 'a'
causing a cycle.

/ Jonas

Received on Saturday, 12 September 2009 21:33:27 UTC