Comment on attachment 678594 [details] [diff] [review] Patch (v1) Can we get this spec to stop using magic numeric constants and use WebIDL enums instead (which look like strings in JS)? r=me modulo that.

I filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19872> for the former. The values that I have used in this patch are stolen from The Real Spec (WebKit source code) (sigh...) I have brought up using Web IDL enums before, but crogers mostly thinks that using them doesn't have much of an advantage, plus he's worried that switching the syntax now will break existing code...

It has several advantages, including less typing for actual consumers if they want to have the code readable, the inability to write unreadable code, and better ability on the part of the browser to enforce the right set of values... How would existing code break? Are people shipping this API unprefixed?

Backed out for build bustage: https://hg.mozilla.org/integration/mozilla-inbound/rev/13d927597146

(In reply to Boris Zbarsky (:bz) from comment #5) > It has several advantages, including less typing for actual consumers if > they want to have the code readable, the inability to write unreadable code, > and better ability on the part of the browser to enforce the right set of > values... How would existing code break? Are people shipping this API > unprefixed? I'm with you on all this. Nobody has been shipping the API unprefixed, but there are various demos out there relying on webkitAudioContext which I guess Google is not quite willing to break... :(

There's no real reason they can't put the right API on AudioContext but leave the thing they have on webkitAudioContext. I understand if we can't convince them, but ... <sigh>.

So, looking into the build bustage, it seems like gcc 4.4 cannot compile this program: enum class X : unsigned short { x, y }; int main() { X a = X::x; return a > X::y ? 1 : 0; } It just doesn't seem to have an operator> which takes arguments of the enum class file. Therefore I think that we should up the enum class prerequisite to gcc 4.6 (which I'm sure can handle this), and just use our workaround for older gcc's.

(In reply to Boris Zbarsky (:bz) from comment #8) > There's no real reason they can't put the right API on AudioContext but > leave the thing they have on webkitAudioContext. I understand if we can't > convince them, but ... <sigh>. This is the thread where we discussed this, FWIW: <http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0805.html>

Upon further investigation, gcc 4.5 gets this right as well.

https://hg.mozilla.org/integration/mozilla-inbound/rev/789fceea31b7 https://hg.mozilla.org/integration/mozilla-inbound/rev/8bff3d974e9e

https://hg.mozilla.org/mozilla-central/rev/789fceea31b7 https://hg.mozilla.org/mozilla-central/rev/8bff3d974e9e

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.