- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 09 Apr 2012 13:06:29 +1000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: Kenneth Russell <kbr@google.com>, Glenn Maynard <glenn@zewt.org>, public_webgl@khronos.org, "public-script-coord@w3.org" <public-script-coord@w3.org>
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