W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: IDL: number types

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
Message-ID: <D58DA175CEFB4ADEA33E6C0C3B2E42CA@marcosc.com>

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.  
> * "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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC