RE: IDL: number types

This is kind of a meta-question, but is the purpose of IDL types for C++ implementers or for JavaScript consumers?

The way Boris talks about them, it sounds like they are being used directly for C++ implementations. But my impression was that WebIDL was supposed to be specifying JavaScript objects created through the parser, in which case there should only be a single number type (aka "Number").

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

________________________________________
From: Marcos Caceres [w3c@marcosc.com]
Sent: Wednesday, March 20, 2013 12:28
To: Boris Zbarsky; Yehuda Katz
Cc: Anne van Kesteren; public-script-coord@w3.org
Subject: Re: IDL: number types

Cc'ing Yehuda, as he was the one that brought this up during the TAG meeting this week. He can articulate his concerns and the confusion better…

On Wednesday, 20 March 2013 at 12:13, Boris Zbarsky wrote:

> On 3/20/13 9:50 AM, Marcos Caceres wrote:
> > However, the octet behavior could be redefined in prose if need be.
>
>
> Please let's not do that. The point of having a single IDL spec for
> stuff like this is to avoid every single spec that wants the behavior
> having to (probably buggily) define it in prose.

I agree - and this is the value of WebIDL. What I meant was that, if we do away with the actual types, we could still leave the algorithms in the spec (or somewhere) for editors to use.

What I am trying to understand is what types are being used by authors today and why? For instance, why does the XHR spec really need to use an "unsigned short" for a set of constants that go from 0-4 (instead of an octet)? And so on.

> > I think the are potentially helpful, but you could have them as generic prose algorithms and not part of WebIDL itself.
>
> I would be fine with generic prose algorithms in a centralized location,
> so they're only done once. But what's the benefit of that over having
> them just available in IDL?

I also don't mind where these things end up, just about their utility and availability. The argument (complaint?) being made, as I understand it, is that the current numeric types in WebIDL don't have equivalents in ES itself (and apparently, this leads to confusion in certain cases - I personally don't get confused, but I can see why other people might).

Received on Wednesday, 20 March 2013 16:35:02 UTC