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

Re: IDL: number types

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 20 Mar 2013 13:25:45 -0400
Message-ID: <5149F119.1090308@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Marcos Caceres <w3c@marcosc.com>, Yehuda Katz <wycats@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 3/20/13 12:33 PM, Domenic Denicola wrote:
> This is kind of a meta-question, but is the purpose of IDL types for C++ implementers or for JavaScript consumers?


The purpose of IDL types is to define the behavior of the APIs.

In a number of cases, the behavior is indistinguishable no matter what 
IDL type you use.  For example, the readyState of an XHR could be any 
numeric type you want, and it would all look the same.

In other cases, the behavior very much depends on the IDL type used; a 
sequence<octet> argument has quite different behavior from a 
sequence<double> argument.

> The way Boris talks about them, it sounds like they are being used directly for C++ implementations.

This may be implementation-dependent.  Gecko maps the IDL numeric types 
directly to (u)int*_t types in C++.

> But my impression was that WebIDL was supposed to be specifying JavaScript objects created through the parser

No idea what that last bit means.

> in which case there should only be a single number type (aka "Number").

ES has only one "user-consumable" type (IEEE double), but has various 
built-in facilities for converting that type to various integer types 
and performing integer operations on those.  The question is whether and 
how to express those facilities in IDL.

> Clarifying the purpose of WebIDL might be a good starting point for any attempts to nail down its type system.

The purpose of WebIDL, from my point of view, is to provide syntactic 
constructs for common semantic behavior of APIs so that:

1)  Specification authors do not have to keep manually redefining common 
semantic behaviors but can instead reference a standard definition.

2)  It's easy to tell at a glance what (some of) the semantics of a 
method or property are.

#2 in practice can be combined with the fact that IDL is 
machine-parseable to autogenerate some of the implementation of the 
semantics from the IDL, making implementation simpler.

Received on Wednesday, 20 March 2013 17:26:20 UTC

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