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

Re: IDL: number types

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 20 Mar 2013 13:54:48 -0400
Message-ID: <5149F7E8.7000302@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Anne van Kesteren <annevk@annevk.nl>, Marcos Caceres <w3c@marcosc.com>, Yehuda Katz <wycats@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 3/20/13 1:41 PM, Domenic Denicola wrote:
>> A property specified as "unsigned long" in IDL takes its input, converts it to a JS Number, then applies ToUint32 from the ES spec, then works with the result.
> That was what I was curious about; thanks! So it's this pattern WebIDL is meant to encourage.

I wouldn't call it "encourage".  Rather, "enable".

As in, _if_ you want this behavior, _then_ you want your IDL to say 
"unsigned long".

If you want some other behavior, then you should express the behavior 
you want in IDL accordingly.

I do think that some of the IDL types we have now are more likely to 
lead to a better API than others, and it may be worthwhile to give more 
prominence to them.

> Essentially it is a declarative way of doing the argument-type coercion you find in the ES spec, e.g. step 5 of http://es5.github.com/#x15.3.4.3

For integer types, precisely.

> In that case I'd imagine the number types you'd want are Number, Integer, Int32, Uint32, and Uint16.

What would "Integer" do?

But also, this depends on your use cases.  For example, if we want to 
allow passing in arrays (not typed arrays, but JS arrays) of byte values 
for some reason, then we may need a way to describe that.

It all comes down to what web specs are actually trying to do.

ES itself will presumably be introducing various To* conversions for its 
definition of typed arrays and DataViews.  Do we expect web specs to 
need conversions like those in other contexts?  Those are the questions 
we should be asking ourselves.

Received on Wednesday, 20 March 2013 17:55:18 UTC

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