Re: IDL: number types

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.
* "byte" seems to be pretty much unused.
* "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.  ;)

-Boris

Received on Tuesday, 19 March 2013 13:12:13 UTC