[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

I forgot, I talked with Cameron on IRC a while back about the dictionary vs. callback thing:


The short of it is that if callback is used, all of the members need to be nullable, since they're all optional when passed to getContext; or else getContext will get a TypeError when reading them, I think?  I'm not sure.

On Sat, Mar 31, 2012 at 9:42 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
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 agree that it's currently underdefined.  I recommended defining this explicitly: https://www.khronos.org/webgl/public-mailing-list/archives/1112/msg00037.html ("Convert options to an IDL value of type WebGLContextAttributesInit...").  I think that fell through the cracks (ping @ Kenneth).
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.

Honestly, I'm not sure I'm a fan of the "single getContext method" approach in the first place.  I think it would have been better to have context specs define their own getContext method (eg. getWebGLContext) supplementing HTMLCanvasElement, and for Context to just give a framework for that.  Oh, well.

I'm not sure if a syntax specifically for this would be a good idea, because I'm not sure people should be mimicing it and there's only one place it'd be used right now (2d canvas doesn't take any other parameters)...

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.

Right, the type would have to be defined twice, which would be a bit redundant, though it'll always be a simple type so it's not that big a deal.

You *can* return a dictionary type from functions, so it could, in fact, just define a dictionary used by both getContext and getContextAttributes.  It'd lose the interface, but I can't think of any use cases for an interface there anyway.  But I guess there's otherwise no real difference between doing that and just making the attributes nullable.

Glenn Maynard