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 09:53:24 -0700
Message-ID: <CAMFeDTWXD-HxhsnBKm9RxMhiGyaSM5gV6K+stxzyjzt9=zzUiw@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>
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
Received on Wednesday, 20 March 2013 16:54:11 UTC

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