Re: Help with WebIDL v1?

On Mon, 1 Dec 2014, Boris Zbarsky wrote:

> On 12/1/14, 1:49 PM, Travis Leithead wrote:
>> I believe so; this will give many specs a baseline WebIDL document to point 
>> to in their references at the very least. Many specs don't rely on the more 
>> advanced feature set being defined in WebIDL Second Edition.
>
> Here's the problem.
>
> As of today, v2 is not just v1 plus some more features.  They actually have 
> some disagreements on how identical IDL syntactic constructs are handled. 
> For example, sequence behavior is different: in v1 a sequence has magic for 
> platform array objects and the gets the "length" property and goes from 0 to 
> length, while in v2 a sequence is an iterable and uses the ES6 iterator 
> protocol.

Pretty much like refactoring XHR using Fetch or not. Most implementations 
will most probably move to the latest version, but the external interface 
will be the same. In the case of Sequence, the ES binding says in the two 
versions "IDL sequence<T> values are represented by ECMAScript Array 
values."

The option 2 you outline seems best here, the syntax is considered as 
stable (well, can be expanded, things can be declared obsolete, but there 
won't be breaking changes), but implementations (as in the es binding 
algorithms) may change to match the evolution of the underlying language.

> Or another example: in v1 having an indexed getter implies nothing about 
> being iterable, but in v2 it implies ES6 iterability.

This is an example of v1 plus one feature.

> More generally, v1 is pretty much defined in ES5 terms, while v2 is aiming 
> for closer convergence with ES6.
>
> What happens when a spec uses a sequence argument and references v1? Are UAs 
> supposed to implement the v1 behavior or v2 behavior?
>
>> However, let's not hijack this thread; I'd love to hear what the next steps 
>> are for moving this v1 forward.
>
> I think that actually depends on how we want to handle the problem I describe 
> above.
>
> Some obvious options are:
>
> 1)  Backport all behavior changes from v2 to v1 so they agree on the set of 
> syntactic constructs supported by v1.  This makes v1 depend on ES6, which I 
> understood to be a non-goal (or perhaps even anti-goal, given ES6 is not 
> finalized yet?  But it's close).
>
> 2)  Treat v1 as a syntax spec (with v2 a superset of the syntax) and 
> explicitly say somewhere in v1 that v2 can redefine the behavior.  Not sure 
> how happy people referencing v1 will be with that.
>
> Other options?

Another option would be to define only the syntax and leave the bindings 
to v2 only, but it wouldn't help much for testing.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 3 December 2014 14:03:00 UTC