Re: Better event listeners

On Thu, Jan 10, 2013 at 6:47 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jan 10, 2013 at 3:35 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > In order for that to work you need to do selector-based filtering of
> > event.target, not event.currentTarget.
>
> Yeah, my bad.
>

(Just sanity checking: you're getting my mail, right?  I mentioned this
early in the thread.)


On Thu, Jan 10, 2013 at 7:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jan 10, 2013 at 2:38 PM,  <brandon.wallace@yahoo.com> wrote:
> > I believe it has been mentioned that an object leaves the door open for
> future enhancements.  Returning only a function limits your options for
> future enhancements.
>
> Given that there's ample precedence for such APIs in setInterval() and
> such I'm not too worried about that. Enhancements will always be
> possible one way or another. Memory usage and added complexity are
> also considerations.
>

setInterval is a terrible legacy API that shouldn't be mimiced.  It has no
isolation between code; any script can do for(i=0; i<100000;++i)
clearInterval(i); and clear timers for code it has nothing to do with.
 This isn't possible with event listeners: if you don't have a reference to
the appropriate object--the listener function, currently--it's impossible
to accidentally unregister it.

I don't know why returning a function would use less memory than returning
an object, since functions *are* objects, and the function would still need
to be a closure.  (I wouldn't be surprised if implementing the function
version is actually more work in some browsers, since while returning an
object is commonplace, creating a closure from native code may be less
common.  But I'm not an implementor, so a parenthetical...)

On Fri, Jan 11, 2013 at 7:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> What future headaches? As I said before, thus far we never found a
> need to expand this kind of API. See setInterval(),
> addEventListener(), ...


setInterval is orders of magnitude simpler API than DOM events, so it isn't
a useful comparison.  I don't understand the reference to addEventListener
(events are exactly what we're talking about expanding on right now).

I've already given an example of something else this API might do in the
future, based on an actual, live API.
http://prototypejs.org/doc/latest/dom/Event/Handler/prototype/start/index.html


On Thu, Jan 10, 2013 at 9:19 AM, Robin Berjon <robin@w3.org> wrote:

> Actually, just because it's a function doesn't mean it can't be extended:
>
> var obj = function () { console.log("stop"); };
> obj.start = function () { console.log("start"); };
> obj();
> obj.start();
>
> Whether that's elegant is another question.


This is exactly the sort of nasty contortion I mentioned earlier--something
we clearly wouldn't want to have to do.

Returning an object is also clearer, since it gives the method a name;
returning a function is opaque.  I don't know why we'd deviate from the
standard pattern here.

-- 
Glenn Maynard