Re: addEventListener naming

On Wed, Aug 26, 2009 at 7:30 PM, Doug Schepers<schepers@w3.org> wrote:
> Hi, Alex-
>
> Thanks for the reply.
>
> The DOM3 Events work is now going to the mailing list www-dom@w3.org, so I
> am CCing that list.  Same group (WebApps WG), just a different list so I can
> better concentrate.
>
> Ignore everything I said about event aliasing... I don't know what I was
> thinking, this is a method, not an event type... I was probably tired or
> rushed at the time.
>
> Replies inline...
>
> Alex Russell wrote (on 8/26/09 7:24 PM):
>>
>> Wow, I just found this thread again. I suck for having not replied
>> earlier. Sorry 'bout that. Comments inline.
>>
>> On Fri, Apr 24, 2009 at 3:23 PM, Doug Schepers<schepers@w3.org>  wrote:
>>>
>>>  Hi, Alex-
>>>
>>>  Alex Russell wrote (on 4/24/09 5:31 PM):
>>>>
>>>>  The DOM function "addEventListener" is probably too long. It should,
>>>>  instead, be named something much shorter owing to the amount of
>>>>  exercise it receives. Further, it should default the last parameter to
>>>>  be "false" (non-capture-phase). This call:
>>>>
>>>>      node.addEventListener("click", function(e) { /* ... */ }, false);
>>>>
>>>>  Should be able to be written as (e.g.):
>>>>
>>>>      node.listen("click", function(e) { /* ... */ });
>>>>
>>>>  Similarly, "removeEventListener" should be aliased as "unlisten". As a
>>>>  further help, the common-case operation of listening-for-a-single-call
>>>>  is currently written as:
>>>>
>>>>      var h = function(e) {
>>>>          /* .... */
>>>>          node.removeEventListener(h);
>>>>      };
>>>>      node.addEventListener("click", h);
>>>>
>>>>  And given how common this operation it, it should probably have an
>>>> alias:
>>>>
>>>>      node.listenOnce("click", function(e) { /* ... */ });
>>>
>>>  Obviously, we can't get rid of "addEventListener" or
>>> "removeEventListener".
>
> ...
>>
>>>  Personally, I'm fine with your suggestion, and I'd be fine with putting
>>> it
>>>  into DOM3 Events on the EventTarget interface.  Here are some of the
>>>  challenges that would need to be overcome:
>
> ...
>>
>> 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).

>>>  1) browser implementers would have to sign off on it, and commit to
>>> putting
>>>  it into browsers
>>
>> That's just a constant for any new proposal.
>
> Yup.  So, implementers... what do you think?
>
>
>> Preferably, the DOM WG
>> shouldn't pick this up until there's at least one implementation,
>> right?
>
> Not necessarily.  If we do decide put it in DOM3 Events, it would be with
> the agreement of implementers who have already committed to implementing it,
> so it's just another method to implement.
>
> (BTW, there is no DOM WG anymore... the WebApps WG is maintaining and
> building on the DOM specs.)
>
>
>>>  3) what would we do for older browsers that don't understand the new
>>> method?
>>
>> They're screwed anyway. Progress should not be held up by old browsers.
>
> I wasn't arguing against adding the feature... I'm asking "how do we solve
> the problem of older browsers?"  I can see a comprehensive script lib being
> useful for a whole range of DOM3 Events stuff.  The active participants in
> the DOM3 Events work

To some great extent, we have something similar in libraries today.
Something like dojo.connect(obj1, "onfoo", obj2, "methodToBeAdvised")
would be the natural equivalent of:

    obj1.listen("foo", obj2.methodToBeAdvised);

>>>  I like your idea of "listenOnce()".  Would that also be removed by
>>>  "unlisten()" in case the author wanted to cancel it, or would it require
>>> its
>>>  own remover?
>>
>> Whichever comes first = )
>
> Okay.
>
>
>>>   Is it worth thinking about simply adding an optional parameter
>>>  to el.listen( "evtname", function(e) {}, number-of-times-to-listen )?
>>>   (Probably not.)  Listing some use cases for it might help this along.
>>
>> It'd be nice of a listen() could take optional positional params to
>> treat as partial applications, but that's sort of a higher-order
>> discussion to have about how to pack arguments (i.e., if we peel back
>> the format of Event objects, could you coerce arguments into Event
>> objects?).
>
> Okay.
>
> 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.

> It's nice
> syntactic sugar, but I would rather add functionality along with it, if we
> are going to do something.  So, take it another step... if we were to add a
> new method for listening to events, what extra functionality would it be
> nice to have?  Can we look to script libs or proprietary frameworks for
> inspiration?  One simple thing might be the suggestion above to have the
> number of times to listen for an optional third parameter.  Another one
> might be the ability to pass string parameters that will be passed along to
> the handler.  Some new functionality might justify adding it, and solve
> other problems than just the length of the method name.

Rate-limiting has always been a problem. Also, I didn't mention it
before, but generating events today is just a travesty. It's terrible,
particularly for kbd events. Making it work more like function
dispatch and less like cons-ing up some sort of funky implementaiton
object with opaque params would be a step in the right direction.

Regards

> We are winding down on new features for DOM3 Events (trying to get it out
> the door), but if there's a lot of implementer enthusiasm on this, we could
> put it in.  Any implementers care to chime in?
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

Received on Thursday, 27 August 2009 08:11:09 UTC