Re: addEventListener naming

Hi, Alex-

I've tentatively added the 'listen()' and 'unlisten()' methods as 
syntactic sugar shorthands for 'addEventListener()' and 
'removeEventListener()'.  Obviously, this assumes that the implementers 
have no objections, and are willing to implement these methods.

More replies inline...

Alex Russell wrote (on 8/27/09 4:10 AM):
> On Wed, Aug 26, 2009 at 7:30 PM, Doug Schepers<schepers@w3.org>  wrote:
>>>    Alex Russell wrote (on 4/24/09 5:31 PM):
>>>>>    And given how common this operation it, it should probably have an
>>>>>  alias:
>>>>>
>>>>>        node.listenOnce("click", function(e) { /* ... */ });

I didn't include the 'listenOnce()' method, pending more explicit use 
cases.  And as Sergey says, it's pretty trivial to work around this.

I thought more about my proposal to add an iterator parameter, but 
decided it was probably to complicated to justify, so I kept it simple.


>>  Alex Russell wrote (on 8/26/09 7:24 PM):
>>
>>>  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).

Well, this working group is not the right place to pursue adding 
features to ECMAScript, but if these methods do make it into the DOM3 
Events Recommendation, that might be the first step to appealing to TC39 
to include it in ECMAScript as well.  We might want to make sure that 
the specific parameter types don't conflict with what would be needed 
for ECMAScript.


>>  My chief issue to the general idea of adding "listen()" is that it doesn't
>>  actually do anything that "addEventListener()" doesn't do.
>
> ...until we get some unification with base JS types, no, that's true.
> It does, however, remove a terrible API name. That alone is worth a
> lot.
>
> FWIW, I don't think something like listen() should be done in
> isolation. It should be accompanied by a whole new suite of
> better-named APIs for common DOM operations across the board. It's
> just the first thing on my list.

We are open to suggestions, but personally, I think designing new 
functionality trumps renaming, so in general I am concentrating on that.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 12 September 2009 20:19:40 UTC