Re: [WebIDL] Simplify callbacks

David Flanagan:
>> In order to achieve that simplification, Anne suggested
>> standardizing handleEvent() as the method name. No one likes that,
>> but the basic idea is still an interesting one, if a suitable
>> WebIDL syntax can be devised.  Some sort of WebIDL function type
>> that is parameterized by (or annotated with) an allowed method name
>> and also argument types if those are necessary.  So then we could
>> declare methods like addEventListener without an EventListener
>> interface:
>>
>> void addEventListener(DOMString type, [MethodName=handleEvent]
>> function<Event>? listener, optional boolean capture);
>>
>> I'm not convinced that a suitably non-ugly syntax can be devised,
>> however, and I don't know what Cameron thinks about this sort of
>> wholesale alteration to WebIDL syntax.

Brendan Eich:
> A JS function has a call method, of the form
>
> return_type call(this_type, arg1_type, ... argN_type)
>
> What if we standardized on a "Delegate" interface that has a call
> method with a suitably generic (in terms of types) form of this
> signature? Then you could pass JS function objects or
> Delegate-implementing objects equally well.
>
> Using call instead of callback and making the receiver the first
> parameter, shifting the event object over one, could be interfaced to
> the existing EventListener legacy by defining a suitable call method
> on a prototype (in a WebIDL interface), with the implementation just
> forwarding, e.g.
>
> EventListener.prototype.call = function (target, event) { return
> target.handleEvent(event); }
>
> I may be missing something, but function objects in JS already have a
> "handleEvent" method: call. It does take uncurried |this| as first
> parameter.

I think having new APIs take callback functions with `this` as a 
parameter would be inconsistent with no gain, at least from the author's 
perspective.  I'm also not sure how the EventListener.prototype.call 
definition above helps given that existing code that registers DOM 
Events listeners just uses `({ handleEvent: ... })` rather than `new 
EventListener(...)` or so.

Received on Wednesday, 14 December 2011 01:11:04 UTC