- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 21 Dec 2011 17:27:16 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: public-webrtc@w3.org, hta@google.com
On 12/21/2011 04:45 PM, Tab Atkins Jr. wrote: > On Tue, Dec 20, 2011 at 7:48 PM, Harald Alvestrand<harald@alvestrand.no> wrote: >> On 12/20/2011 11:54 PM, Tab Atkins Jr. wrote: >>> There was no official resolution about this, as it's a style/design >>> thing, not an actual change in the spec. >> So (formalistically) how do observers know that this was the conclusion? >> I'd be happy to be pointed at an email in the archive of the WG saying "as >> WG chair, I conclude that this discussion resulted in....." > I'm not sure I understand - the fact that there's a note in the spec > means that the editor decided to put it there. > > However, the bug that led to Cameron adding this text was > https://www.w3.org/Bugs/Public/show_bug.cgi?id=14878 Interesting discussion - thanks! Now it's clear that at least you, Cameron and Anne are convinced, and nobody's objected strongly on the bug - the fact that this bug tracker CCs the mailing list makes me reasonably confident that there aren't engaged, strong objectors out there. I read a very strong objection to use of bitfields, and a not-quite-so-strong (but still clear) objection to the use of integer constants. >>> However, I can quickly list >>> the reasons why the decision was made: >>> >>> 1. Constants are more verbose than strings of the same name, as you >>> must repeat the name of the interface as well. >>> 2. Numeric constants can be passed in two ways to a function, and the >>> bad way (as integers) is much shorter, and thus often more attractive. >>> 3. Constants don't buy you anything over strings - strings can be >>> interned, etc. >>> >>> In general, experience shows that people usually forgo the named >>> constant and just use the numbers instead, which is the worst outcome >>> possible, as it makes the code very difficult to read and understand. >>> Since using strings instead has no real downsides, and avoids all of >>> the downsides of numeric constants, they are now the preferred way to >>> handle this sort of thing. >> I see the logic. The lack of enums in the language hurts again. >> I still miss the ability to document (for programmers) in WebIDL what the >> permitted values are; is there a comment convention for doing that at the >> moment? > Enums were just added yesterday, due to feedback on an unrelated bug. > ^_^ http://dev.w3.org/2006/webapi/WebIDL/#idl-enums With that addition, and the fact that the API to enums is formulated in terms of strings, I feel confident in recommending that the APIs in WebRTC that use integers for enum-like properties should be changed to use strings. Thank you! Harald
Received on Wednesday, 21 December 2011 16:27:41 UTC