Re: WebGL IDL for uniform1fv is not valid WebIDL

Boris Zbarsky:
> The IDL in question is:
>
>      void uniform1fv(WebGLUniformLocation? location, Float32Array v);
>      void uniform1fv(WebGLUniformLocation? location, float[] v);
>
> Unfortunately if you look at the table at
> http://dev.w3.org/2006/webapi/WebIDL/#dfn-distinguishable you see that
> T[] and an interface type (which is what Float32Array is) are only
> distinguishable if the interface type doesn't support indexed
> properties.  Which Float32Array does, of course.  So this IDL fails this
> requirement from the section linked above:
>
>    If there is more than one entry in an effective overload set that has
>    a given type list length, then for those entries there MUST be an
>    index i such that for each pair of entries the types at index i are
>    distinguishable.
>
> Cameron, I'm not sure why exactly interface types with indexed
> properties are not distinguishable from IDL arrays.  For non-callback
> interfaces, it seems like the UA could tell them apart and we could
> define that the interface version is called if the right interface is
> passed in, else the array version is called.

I want to allow object with indexed properties to be passed to objects 
expecting a sequence<T> or T[] type, so that you can do for example:

   void f(sequence<Node> nodes);

and be able to pass in a JS Array of Node objects or a NodeList.  I make 
interfaces with indexed properties not distinguishable from sequences 
and arrays so that there isn't a value that would match both types.

> But failing changes to WebIDL, the IDL here would need to change somehow.

I think removing the Float32Array overload will make passing JS Arrays 
of Numbers and Float32Array objects work.  But note that *any* object 
that has indexed properties will be allowed to be passed here, e.g. a 
Uint8Array.  If we want to disallow that, then I think that is 
incompatible with the NodeList example above.  But if we're fine with 
Uint8Array being passed in and matching the float[] overload, then just 
changing those types to be distinguishable, and making the argument 
resolution algorithm match the specific interface types before the 
"catch all" array/sequence types should work.

Received on Monday, 2 April 2012 23:21:36 UTC