- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 20 Mar 2013 09:50:51 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Anne van Kesteren <annevk@annevk.nl>, public-script-coord@w3.org
On Tuesday, 19 March 2013 at 09:11, Boris Zbarsky wrote: > On 3/19/13 7:02 AM, Anne van Kesteren wrote: > > The context is continued complaints about IDL's mismatch with > > JavaScript. The last time I brought up simplification of the various > > numeric types it was brought up that ArrayBuffer and friends relied on > > the various C types. Now ArrayBuffer will no longer rely on them by > > being natively defined in ES6 I was wondering whether we could do > > this, or if there are some other reasons why we have these types that > > do not match JavaScript's floating point. > > > > > So what this is really about is getting rid of all types that are not > "(unrestricted )?double", "long", and "unsigned long"? Or are you > proposing getting rid of one of those too? > > So I just took a quick look at where other numeric types are used in > Gecko's WebIDL (which doesn't cover everything in the web platform yet): > > * "octet" is used in "sequence<octet>" in DOMParser in a > non-web-exposed parseFromBuffer. Not clear to me whether > sequence<octet> is something other consumers might want in > general. > Also in Web MIDI, though not implemented AFAIK. However, the octet behavior could be redefined in prose if need be. https://github.com/WebAudio/web-midi-api > * "byte" seems to be pretty much unused. > Agreed. I've not seen any instances of this. > * "short" and "unsigned short" are used for various constants and state > fields (readyStates, nodeTypes, etc). Obviously anything returning > "short" could just return "long". Not sure about things that _take_ > "short" values, in terms of compat. Note that things that return > "unsigned short" are somewhat faster than things that return > "unsigned long" at least in JS implementations that have 32-bit > signed int values but not 32-bit unsigned int values. > * "float" is used all over webgl in sequence<float> form and various > places in SVG. Those _could_ use double and just coerce to float in > the implementation, but for restricted floats that's a behavior > change, since the value can become Infinity after the coercion. > > Not sure what to make of all that yet. ;) I think the are potentially helpful, but you could have them as generic prose algorithms and not part of WebIDL itself.
Received on Wednesday, 20 March 2013 13:51:25 UTC