W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Using Web IDL enums instead of numeric constants

From: Chris Rogers <crogers@google.com>
Date: Mon, 24 Sep 2012 15:58:33 -0700
Message-ID: <CA+EzO0n7heu4xTPQXH6wMcAnkzOc6U1jc3HDp21+RP7R_8uPZA@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: olivier Thereaux <olivier.thereaux@bbc.co.uk>, public-audio@w3.org
On Mon, Sep 24, 2012 at 3:31 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Fri, Sep 21, 2012 at 12:03 PM, olivier Thereaux <
> olivier.thereaux@bbc.co.uk> wrote:
>> Hi Ehsan,
>> On 21 Sep 2012, at 16:55, Ehsan Akhgari wrote:
>> > Should we consider using Web IDL enums instead of numeric constants for
>> things in the spec which are actually enumerated values?
>> I recall we had an issue about that. Ah, yes:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17323
>> The bug is currently closed, my bad as I thought we'd fixed all the
>> IDL-related issues with your recent set of changes. Feel free to reopen it.
>> As for you question, if indeed enums are more expressive and closer to
>> our spec in prose, I see no reason to not use them.
> Just to make it clear, it will break the existing implementation in WebKit
> since the API will change to use strings instead of numbers.  Is that OK?

If people feel very strongly, we can move away from the numeric constants.
 But WebKit would continue to also support the old syntax during a certain
time so we could transition in an orderly fashion.

As far as what style of constants we should use, I don't have a strong
preference, but would note that WebGL uses numeric constants.

To some extent, it feels like we're moving into bike-shedding territory,
and I'd like to carefully consider how important any name changes really
are.  These name changes *do* take a toll on the developers who already
have invested time in writing production code.


> Thanks!
> --
> Ehsan
> <http://ehsanakhgari.org/>
Received on Monday, 24 September 2012 23:01:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC