Re: Better event listeners

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

> > 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).
>
> It is a useful comparison as it's the same kind of problem: adding and
> removing a callback. It seems you trimmed down too much here, it gave
> the reasons for why an object is problematic.
>

You're saying "we've never needed to add other behavior to the return value
of setInterval, therefore we probably will never need to do so for event
handlers", which is drawing a conclusion from a bad comparison, IMO.

I trimmed a reason I responded to elsewhere (which you trimmed :), and a
non-reason: no, it shouldn't have a constructor since there are no use
cases for one, and it can be added later if they arise.  (Deciding that
isn't an argument against using an object.)

> 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
>
> Is it in use?
>

I don't know.  The point is there are clear downsides (being unusual on the
platform and resulting in slightly less clear code), some possible
downsides (the above), and the arguments for it seem questionable.  The
arguments I've seen for a function are:

- Returning a closure somehow uses more memory than returning an object,
and enough to matter.  This seems questionable.  Do you have data?  Both
create an object that needs to be GC'd; they're just different objects.
- Returning a closure is simpler than returning an object.  Have
implementors actually said they'd implement this if it was a closure, but
not if it was an object, because objects are so complex?

They both feel like premature optimizations to me.

(I could see an object-based API that doesn't create an object requiring
GC, essentially by returning an integer like setInterval, but boxed in an
immutable container that's copied by value.  Copying by value avoids the
need for it to be collected, and boxing it avoids the "clearing timers
accidentally" problem I mentioned earlier.  However, this might be hard to
implement if there's nothing like that in JS engines already.)

On Fri, Jan 11, 2013 at 10:40 AM, James Graham <jgraham@opera.com> wrote:

> I don't think that this mind of micro-optimisation is a valid argument
> here. Creating an event handler isn't something that you have to do
> thousands of times in a tight loop. Indeed with the delegation pattern that
> we are trying to support here you dramatically cut down the number of
> listeners that are required compared to the one-listener-per-target
> approach.
>

My recommendation is that we extend addEventListener, not add a new API.
 (I don't like the idea of adding a whole new API optimized just for
delegation--we should be able to avoid that.)  That means the object would
be returned by addEventListener.  If returning an object from
addEventListener is too much of an added cost, I'd expect returning a
function to be too, though.

-- 
Glenn Maynard