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

Re: IDL: number types

From: Yehuda Katz <wycats@gmail.com>
Date: Wed, 20 Mar 2013 10:04:34 -0700
Message-ID: <CAMFeDTUDkjUmPUN9ahA-aovC1vSPPD6hkCwVC5p8cbHgSE_y+A@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Marcos Caceres <w3c@marcosc.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Mar 20, 2013 at 9:53 AM, Yehuda Katz <wycats@gmail.com> wrote:

> In general, the idea is that we should have a set of declarative tools
> that are generally used for new APIs that map onto JavaScript semantics.
>

I mean map *directly* onto JavaScript semantics. Today, WebIDL reflects a
C/C++ implementation, and maps onto ES through a binding layer.


>
> So in general, spec writers should start with `number`, rather than
> `unsigned long`.
>
> We should also have additional types that are useful for:
>
>    - legacy APIs
>    - very specialized APIs
>
> but these should be clearly separated out, and not the types that specs
> start out with.
>
>
> On Wed, Mar 20, 2013 at 9:49 AM, Anne van Kesteren <annevk@annevk.nl>wrote:
>
>> On Wed, Mar 20, 2013 at 12:46 PM, Domenic Denicola
>> <domenic@domenicdenicola.com> wrote:
>> >> Well, we would still want a distinction between floating point,
>> integer, non-negative integer, floating point without Infinity, -Infinity,
>> or NaN, ...
>> >
>> > Why? JavaScript can't distinguish, so why should WebIDL?
>>
>> Because specification writers forget these details and giving them
>> declarative tools to make writing APIs easier is a good thing. You
>> don't have to think of these things as types, but as a set of initial
>> constraints on the variable that your algorithm gets passed.
>>
>>
>> > Or is the idea that properties specified as non-negative integers
>> should have setters that throw when you set them to negative integers or to
>> floating point numbers?
>>
>> For instance. What exactly we want to do should be in coordination
>> with TC39 and existing API behavior I think.
>>
>>
>> --
>> http://annevankesteren.nl/
>>
>
>
>
> --
> Yehuda Katz
> (ph) 718.877.1325
>



-- 
Yehuda Katz
(ph) 718.877.1325
Received on Wednesday, 20 March 2013 17:05:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC