Re: CHANGE: Remove numeric constants from WebRTC API

* Harald Alvestrand wrote:
>I'm therefore calling for the WG's consensus to do this change.
>It affects at least the following:
>
>- MediaStreamTrack: readyState (LIVE, MUTE and ENDED)
>- PeerConnection: readyState, iceState and sdpState
>
>In all four cases, the current "const unsigned short" declarations woudl 
>be replaced with strings; as I understand the enum spec from WebIDL [1], 
>this:
>
>     const unsigned short LIVE = 0;
>     const unsigned short MUTED = 1;
>     const unsigned short ENDED = 2;
>     readonly attribute unsigned short readyState;
>
>would become this:
>
>     enum ReadyStateType { "live", "muted", "ended" };
>     readonly attribute ReadyStateType readyState;

It seems to me that JavaScript APIs that deal with data flows in some
form mostly use numeric constants, for instance, XMLHttpRequest, the
Websocket API, HTMLTrackElement for timed text tracks, HTMLMediaElement
for <audio> and <video>, various File APIs, the Indexed Database API,
they all use `readyState` and it's always a numeric value. Most of them
are unlikely to switch of enums for compatibility reasons, either they
will stay as they are, or there will be some general-purpose mechanism
to change them all in a consistent manner (like overloading comparison
operators so you can use strings but code expecting numbers is unlike-
ly to break).

I also note that instead of enums string constants could be used. That
would allow for the current idiomatic x.readyState == x.CONSTANT while
also allowing for the direct enum usage x.readyState == "CONSTANT".

I think the Working Group should pass this question on to the folks on
<public-script-coord@w3.org>. I do agree that there is a general senti-
ment to prefer strings over numeric constants, but whether that applies
to readyState-ish APIs is unclear given existing API design patterns.
Another question would be whether the name `readyState` should be kept
if WebRTC does switch to enums or something else.

I also note in passing that numeric constants are mostly unpopular as
browser vendors do not implement them well. The "OPENED" constant for
XMLHttpRequest has been in the XMLHttpRequest proposal since mid-2007,
but even in 2012 code like

  var x = new XMLHttpRequest();
  alert(XMLHttpRequest.OPENED + " " +
        XMLHttpRequest.prototype.OPENED + " " +
        x.OPENED);

alerts "1 1 1" in Firefox but "undefined undefined undefined" in Opera
and "undefined 1 1" in an older Webkit derivative. So numeric constants
often means developers have to put the magic numbers in their code and
that is unpopular obviously.
-- 
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 Wednesday, 18 January 2012 20:31:46 UTC