W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

Re: [WebIDL] Simplify callbacks

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Dec 2011 20:25:03 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
cc: Alex Russell <slightlyoff@google.com>, Cameron McCormack <cam@mcc.id.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Anne van Kesteren <annevk@opera.com>
Message-ID: <Pine.LNX.4.64.1112152018500.17690@ps20323.dreamhostps.com>
On Wed, 14 Dec 2011, Jonas Sicking wrote:
> 
> x = {
>   handleEvent: function(args) {
>     if (... detect first callback type based on args ...) {
>       doStuff();
>     }
>     if (... detect second callback type based on args ...) {
>       doOtherStuff();
>     }
>     etc;
>   },
>   doStuff: function() {...},
>   doOtherStuff: function() {...},
>   moreProps: "here"
> }
> 
> registerCallbackFunc(x);
> registerOtherCallbackFunc(x);

Realistically, I think there is much more chance that a single object 
would be used with multiple instances of the same callback (e.g. 
addEventListener() called with different arguments) or with the same 
callback on many different objects (e.g. toBlob() from many different 
canvas elements) than it is that one object would be used with callbacks 
that happen to have different names.


> So for the sake of not introducing useless features, I would say that
> 1 is strictly better than 2. That way people can use Function.bind and
> direct callbacks directly to where they want.

I would be fine with 1 (and have been arguing that closures are the right 
way to do this for a long time), except that we have a compat need to 
support objects in some places. Given the choice between 2 and 3 I think 2 
is the better choice.

(In the past I've also argued for 4: only support Function in new APIs, 
and in APIs where we're required by compat to support objects, support 
handleEvent. That's actually what the HTML spec required for a long time.)


> I don't think that having to memorize the callback names will be any 
> worse having to remember any other names in the DOM.

The other names can autocomplete. I don't see any sane way an 
autocompleter could know what to autocomplete here.

Also, it's easy to find the name of a method call when looking up 
documentation -- it'll be in the index, for example. For a callback, 
either the index would have to list some specific details of specific 
parameters, or you'd have to actually look up the definition and follow 
the reference from there, etc.


> I think the DOM would be an even worse API if we renamed all functions 
> to "function" and all the properties to "property".

Agreed. But that's not even remotely what we're suggesting here.

A better analogy, IMHO, would be if we had to use a different name for 
"toString()" based on which API we were passing a stringifying object to.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 December 2011 20:26:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC