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

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.

Received on Monday, 9 April 2012 03:07:08 UTC