- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 28 Dec 2011 17:16:02 +1100
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Ian Hickson <ian@hixie.ch>, Alex Russell <slightlyoff@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Anne van Kesteren <annevk@opera.com>
Cameron McCormack: > People will weight the pros and cons differently, I imagine. But for me > based on the above I prefer (c). Based on that, I have changed the spec in this direction so that we move towards accepting Function objects rather than Function objects or plain objects with properties of particular names. I've incorporated a variation of the "callback" proposal (just the single function version) from http://www.w3.org/mid/4EE7F7F7.9080600@mcc.id.au without the function identifier, and this is what specification authors are now recommended to use in place of: [Callback,NoInterfaceObject] interface Blah { ... }; For new APIs (and older ones that don't support the property style), you would write for example: callback CheeseHasArrivedNotification = void (DOMString cheeseType); interface CheeseManager { void requestAsyncCheese(CheeseHasArrivedNotification n); }; and requestAsyncCheese would take only a Function object. [Callback] is now gone altogether, and for the cases where we do need to support a callback object with a property, or any other cases that would currently be handled by [Callback], you define a callback interface. For EventListener, since we need it to continue to support objects with a handleEvent property, we would write: callback interface EventListener { void handleEvent(Event evt); }; with no need for [NoInterfaceObject] since callback interface don't cause interface objects to exist normally. http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.432;r2=1.433;f=h Anne (being the original commentor), I'll assume you are OK with this change unless I hear otherwise. Thanks, Cameron
Received on Wednesday, 28 December 2011 06:16:59 UTC