Re: IDL: number types

Sorry to be late to the thread (which I helped start via the TAG meeting
discussion).

On Wednesday, March 20, 2013, Domenic Denicola wrote:

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

It's a bridge language from *whatever* implementation language there is to
JavaScript. Note that the word "C++" only occurs twice in the spec, and
only in 3.9 where it discusses that the backing for the described
interfaces might be either C++ or JS. That said, it's clearly got the
lineage of a C++ IDL and that's where many of its more-constrained-than-JS
types come from.


> 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.
>

In the past we've been successful as clarifying that it is for describing
JS APIs (not JS + Java APIs). I think these sorts of clarifications are
useful follow-ons.


> ________________________________________
> From: Marcos Caceres [w3c@marcosc.com <javascript:;>]
> Sent: Wednesday, March 20, 2013 12:28
> To: Boris Zbarsky; Yehuda Katz
> Cc: Anne van Kesteren; public-script-coord@w3.org <javascript:;>
> 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).
>
>
>
>
>
>
>
>
>