Re: [WebIDL] Simplify callbacks

I like this idea. [Callback(Event)] EventListener? seems more flexible than
Callback(Event) in that it can use a name other than handleEvent when
dealing with an object.

Web Audio, for example, has a callback for processing audio buffers.
handleEvent is a weird name for this since it doesn’t handle events.

What about (future) callbacks that have return types or raise exceptions?

Dominic

On Tue, Nov 8, 2011 at 10:04 AM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  FWIW, I like the idea. The current indirection through an interface
> annotated with [Callback] has historically been hard for newbies to WebIDL
> to figure out. Anne's concept helps reduce the indirection. ****
>
> ** **
>
> Another syntax could be:****
>
> ** **
>
> addEventListener(DOMString type, [Callback(Event)] EventListener?
> listener, optional boolean capture)****
>
> ** **
>
> Which re-uses the "constructor" parameter syntax (in an extended
> attribute) that we already have in WebIDL.****
>
> ** **
>
> *From:* ojan@google.com [mailto:ojan@google.com] *On Behalf Of *Ojan Vafai
> *Sent:* Tuesday, November 08, 2011 9:05 AM
> *To:* Anne van Kesteren
> *Cc:* public-script-coord@w3.org
> *Subject:* Re: [WebIDL] Simplify callbacks****
>
> ** **
>
> I support this. While it's not the API I'd design from scratch, I think
> it's what we're stuck with and the simplicity provided by doing this
> throughout the platform is worth it.****
>
> On Tue, Nov 8, 2011 at 6:47 AM, Anne van Kesteren <annevk@opera.com>
> wrote:****
>
> It seems that all callbacks use handleEvent() and we cannot change that at
> this point I think. We should simplify callback syntax to a) make IDL
> easier to read and b) ensure consistency throughout the platform.
>
> addEventListener(DOMString type, Callback(Event)? listener, optional
> boolean capture)
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/****
>
> ** **
>