W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: addEventListener and side-effects

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 06 Sep 2011 23:44:54 +0200
To: Robin Berjon <robin@berjon.com>
Cc: www-dom@w3.org, public-device-apis@w3.org
Message-ID: <e3kc675oflgflou7bdvv6ceoc6tr2eb97k@hive.bjoern.hoehrmann.de>
* Robin Berjon wrote:
>In both cases we have a situation in which registering an event using
>addEventListener() is said to immediately (but asynchronously) trigger
>an event for the given event type.

The first test you should put into the test suite then is what happens
if the listener registers itself when triggered, and contact developers
of debugging tools that they can't add listeners for these events since
that would change how the code they are supposed to help debugging be-
haves. Similarily, in the FAQ, the first question to answer would go a-
long the lines of "I did this seemingly unrelated thing but now battery
status code behaves strangley, why?" And by the looks of it the next,
"How do I get the status directly without waiting for an event, to warn
users their battery will run out half way through the live stream they
are about to pay for?".

You want to bind code to an object for synchronization purposes, keep
the battery meter in sync with the actual battery status, or tell your
favourite advertisement corporation where you plug in your device, or
whatever. Doing that by monitoring state transitions is rather fragile,
it's quite common for instance that applications break because you've
switched out of a state through unexpected transitions, like dragging
and then releasing the mouse button outside the area where mouse events
were expected, so the applications thinks you drag while you don't. If
instead you had told the system you want to synchronize with the cursor
in a certain area, odds are much better that this does not happen.

Anyway, there isn't really much to comment on here as you do not offer
the rationale for using the event system to begin with instead of some
alternative; you could make a getBatteryStatus(callback) function that
returns true or whatever if it wants to be called with updates for in-
stance, which is a common idiom, or have a system like

  .batteryStatus.bind("sync", callback); // called "now" and "later"
  .batteryStatus.bind("crit", callback); // called when "critical"
  ...

or whatever, but you ended up using events, and without understanding
why, what discussion you already had about this, we can't develop an
idea of what might be best for your specification without rather use-
less back and forth. What you are proposing is clearly an abuse of the
event system that is likely to cause minor problems, but if that is
the best people can come up with, staring a little deeper down into
the abyss won't change much at this point, the princess is in another
castle, anyway.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 6 September 2011 21:45:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT