Re: [WebIDL] Simplify callbacks

Either we embrace object-with-property for all APIs that take callbacks, 
giving them meaningful method names, or we decide that all future APIs 
take only Functions.  Allowing object-with-property for new APIs but 
using handleEvent for them all seems like a sucky compromise to me. 
Even if we make the name optional, I reckon we'll end up in a worse 
situation than we're in currently, where some spec authors include it 
and others don't.

My memory is hazy on whether we agreed at TPAC whether we should drop 
=FunctionOnly altogether or not, but we did I think settle on allowing 
object-with-properties everywhere feasible.  So I think we should do the 
following:

* Leave FunctionOnly (or some equivalent mechanism) so that we can 
specify the behaviour of event listener attributes.

* Warn in the spec against using FunctionOnly except for event listener 
attributes.

* Encourage spec writers not just to copy DOM Events' name "handleEvent" 
and instead come up with something meaningful for the particular API 
being designed.

* See if we can come up with nicer syntax than:

   [Callback,NoInterfaceObject]
   interface EventListener {
     void handleEvent(Event evt);
   };

We need a place to put the method name in case the object-with-property 
pattern is used by the author.  As David Flanagan says, it might be hard 
to come up with concise, readable syntax.

Anyway, here's a suggestion:

   callback EventListener = void handleEvent(Event evt);

   interface EventTarget {
     void addEventListener(DOMString type, EventListener listener,
                           bool useCapture);
   };

That handles the (by far common case) of [Callback,NoInterfaceObject] 
being used on an interface with a single operation.  It's an improvement 
over using "interface" IMO.

I am not sure now what APIs need [Callback] interfaces with multiple 
operations on them -- I thought there was one spec that wanted this, but 
I can't find it now.  I think perhaps we should have callbacks only as a 
part of the "base" IDL language, and not as an extended attribute.  So 
instead of:

   [Callback,NoInterfaceObject]
   interface CallbackTrio {
     void onStart(DOMString details);
     void onFinish(DOMString details);
     void onError(DOMString details);
   };

we instead write:

   callback CallbackTrio = {
     void onStart(DOMString details);
     void onFinish(DOMString details);
     void onError(DOMString details);
   };

and since it too isn't a real IDL interface, there's no need to write 
[NoInterfaceObject].  But as I say I can't put my finger on what spec 
requires this kind of thing, if there is one.  If there isn't, let's 
drop the above `callback A = { ... }` form.

Also if someone knows of any interfaces that use a [Callback] with 
attributes on it, please let me know.  It would simplify matters to drop 
support for that too.

For event listener attributes where they are required to be restricted 
only to Function objects (that is the case, yes?) we could write

   callback EventListener = void handleEvent(Event evt);
   [FunctionOnly] attribute EventListener onclick;

or

   callback EventListener = void handleEvent(Event evt);
   typedef [FunctionOnly] EventListener EventListenerAttribute;
   attribute EventListenerAttribute onclick;

to reduce a bit of repetition.


I welcome your thoughts on the above.

Received on Wednesday, 14 December 2011 01:12:57 UTC