On Sat, Mar 31, 2012 at 9:42 AM, Boris Zbarsky <email@example.com>
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?
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.
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.
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)...
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.
This could also be done by defining it as a WebIDL dictionary.
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.