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