[Public WebGL] Should WebGLContextAttributes be a callback interface?

Cameron McCormack [email protected]
Sun Apr 8 20:06:29 PDT 2012

Boris Zbarsky:
> On 4/8/12 10:49 PM, Cameron McCormack wrote:
>> Any JS non-platform object can serve as a callback interface object.
> Sure, but even then the "non-platform" restriction is kinda arbitrary.

I guess we could allow:

   interface D { };
   interface E { };
   callback interface F { ... };

   interface G {
     void h(D x);
     void h(F x);

to select the second overload if you pass in an instance of E.  Just not 
sure it's worth it.

>> callback interface A {
>> attribute long x;
>> attribute long y;
>> void f();
>> };
>> interface B {
>> A g();
>> };
>> calling B.g() could return a new JS native object with "x", "y" and "f"
>> properties.
> Yep.  That's what it would do for a dictionary, right?  Or would it not?

It would.

So I think now we can do everything that we'd do with callback 
interfaces with dictionaries then, actually.  Instead of

   callback interface H {
     attribute long x;
     void f();

we can write

   callback VoidFunction = void ();  // already in WebIDL's common defs

   dictionary H {
     long x;
     VoidFunction f;

though I suppose it is less clear.

>> The same question arises with callback functions. If you defined
>> callback SomeCallback = void ();
>> interface C {
>> attribute SomeCallback handler;
>> };
>> should C.handler be allowed to return a Function object that script
>> didn't create? Maybe.
> I wouldn't have a problem with that personally.

OK.  I've removed the restriction again.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list