Re: [Public WebGL] Should WebGLContextAttributes be a callback interface?

On 3/31/12 10:27 AM, Glenn Maynard wrote:
> The IDL is out of date.

OK.  Can the spec at least not link to it, then?  The current setup is 
... confusing at best.

> The idea is that the object you pass to getContext *is* a
> WebGLContextAttributes, as if getContext's signature is WebGLContext
> getContext(DOMString contextId, WebGLContextAttributes attrs), so WebIDL
> takes care of type conversions for the members.

Hmm.  I guess there's no way to actually express this as WebIDL because 
the second argument would need to be of different callback types 
depending on the string value of the first argument and callback types 
are not distinguishable?

But that also means that WebIDL cannot in fact really take care of the 
type conversions, since WebIDL isn't actually being used to define this.

I wonder whether it would be worthwhile to extend overload resolution in 
WebIDL to handle this case by introducing the ability to declare 
overloads where an argument is a constant and treating all constants as 
distinguishable.  So then the IDL for getContext could look like this:

   getContext(DOMString "webgl", WebGLContextAttributes attrs);

or something... The syntax could obviously use improving.

> This could also be done by defining it as a WebIDL dictionary.

Another option would be to define the getContext() argument as a 
dictionary but the return value of getContextAttributes as a 
non-callback type.  Assuming that's useful, of course.  The behavior 
would obviously be observably different (e.g. the properties would then 
live on the prototype), but I'm not sure that gets us anything useful. 
So yeah, probably OK leaving this as a callback.

> No, because getContextAttributes says "Returns a /new/
> WebGLContextAttributes object".

Aha!  Thanks.

-Boris

Received on Saturday, 31 March 2012 14:42:44 UTC