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

On Sat, Mar 31, 2012 at 8:10 AM, Glenn Maynard <glenn@zewt.org> wrote:
> 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).

Sorry about that. It looks like I did drop that set of changes on the
floor by accident. Let's resolve this issue now.

Has there been a decision on the best path forward here? The
requirements in the WebGL spec are relatively small; it must be
possible to pass a user object to getContext("webgl", /* attrs */) and
it must be possible to define the attributes and their types returned
from getContextAttributes. Aside from that the existence of the
WebGLContextAttributes interface is not important.

-Ken


>>
>> 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
>

Received on Tuesday, 3 April 2012 01:52:01 UTC