- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 02 Jan 2012 08:57:15 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Cullen Jennings <fluffy@cisco.com>, public-webrtc@w3.org, hta@google.com
On 12/30/2011 05:19 PM, Tab Atkins Jr. wrote: > On Thu, Dec 29, 2011 at 12:47 AM, Cullen Jennings<fluffy@cisco.com> wrote: >> I'll note that using strings instead of integers is somewhat crappy when an API call needs to be mapped to ENUMs in other programming languages such as C. > We've moved away from caring about languages other than Javascript > when designing web APIs; years of struggling with the turgid horror of > the original DOM (designed for easy compat with Java) taught us that > lesson. ^_^ This is a large part of the reason why we created WebIDL > rather than just continuing to use IDL. > > That said, if an API like this does need to be expressed in another > language where enums are more natural than strings, there's nothing > wrong with defining an enum in their binding. It should just stay out > of the web-facing API binding, which is meant to favor JS. I believe the conversion between a C enum, a Java enum (the 2 are *not* semantic equivalents) and a string should be possible to write as part of WebIDL-parsing/code generation, if needed. What worries me a bit about the WebIDL "enum" proposal is that the semantics of unspecified values is left to the binding, which makes it hard to generate consistent behaviour.
Received on Monday, 2 January 2012 07:57:12 UTC