Re: IDL: number types

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.

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