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:

http://krijnhoetmer.nl/irc-logs/whatwg/20111208#l-281

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