Re: addEventListener naming

Hi, Alex-

I forgot to add a link to the Editor's Draft where I added this.  Please 
review my changes here:
 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#interface-Event

Regards-
-Doug

Doug Schepers wrote (on 9/12/09 4:19 PM):
> 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:25:17 UTC