- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 20 Mar 2013 13:54:48 -0400
- 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. -Boris
Received on Wednesday, 20 March 2013 17:55:18 UTC