- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 24 Nov 2008 23:58:21 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5814 Cameron McCormack <cam@mcc.id.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cam@mcc.id.au --- Comment #2 from Cameron McCormack <cam@mcc.id.au> 2008-11-24 23:58:20 --- (In reply to comment #0) > Right now callbacks are defined in terms of heavy interfaces first, and then > turned into functions for JS. We should make the function form primary, and > make the interface get generated from rules in WebIDL for those languages that > need it. Why? Not all languages support freestanding functions, but languages that Web IDL can target are already required to support interfaces in some form. It makes sense to me to have the interface be the primary means of specifying callbacks. If there were Web IDL syntax to specify the handler function outside of an interface, there would still need to be something to give the name of the interface (and operation name) for non-ECMAScript language bindings, so you may as well just use the interface syntax. > We need some sort of syntax in WebIDL to define callbacks, including the > signature of the callback. What you can do now is: [Callback, NoInterfaceObject] interface MyHandler { void handleEvent(in DOMString something); }; If you specifically want to disallow { handleEvent: function() ... } from being a callback, you can use [Callback=FunctionOnly]. I was considering removing the FunctionOnly (and PropertyOnly) arguments to [Callback] so that callbacks can be implemented in script uniformly, though. (In reply to comment #1) > also make sure TimeoutHandler can be handled by this mechanism [Callback=FunctionOnly, NoInterfaceObject] interface TimeoutHandler { void handleEvent([Variadic] in any args); }; That would handle the current behaviour of most browsers not treating the object's handleEvent property as the implementation of the callback. I think it would be good if implementations did allow this, though, for consistency. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 24 November 2008 23:58:31 UTC