This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5814 - WebIDL: Resolve the callback issue
Summary: WebIDL: Resolve the callback issue
Status: VERIFIED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P4 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NoReply
Depends on:
Blocks:
 
Reported: 2008-06-27 08:34 UTC by Ian 'Hixie' Hickson
Modified: 2010-10-04 13:59 UTC (History)
4 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2008-06-27 08:34:38 UTC
Right now callbacks are defined in terms of heavy interfaces first, and then turned into functions for JS. We should make the function form primary, and make the interface get generated from rules in WebIDL for those languages that need it.

We need some sort of syntax in WebIDL to define callbacks, including the signature of the callback.
Comment 1 Ian 'Hixie' Hickson 2008-07-15 11:11:56 UTC
also make sure TimeoutHandler can be handled by this mechanism
Comment 2 Cameron McCormack 2008-11-24 23:58:20 UTC
(In reply to comment #0)
> Right now callbacks are defined in terms of heavy interfaces first, and then
> turned into functions for JS. We should make the function form primary, and
> make the interface get generated from rules in WebIDL for those languages that
> need it.

Why?  Not all languages support freestanding functions, but languages that Web IDL can target are already required to support interfaces in some form.  It makes sense to me to have the interface be the primary means of specifying callbacks.

If there were Web IDL syntax to specify the handler function outside of an interface, there would still need to be something to give the name of the interface (and operation name) for non-ECMAScript language bindings, so you may as well just use the interface syntax.

> We need some sort of syntax in WebIDL to define callbacks, including the
> signature of the callback.

What you can do now is:

  [Callback, NoInterfaceObject]
  interface MyHandler {
    void handleEvent(in DOMString something);
  };

If you specifically want to disallow { handleEvent: function() ... } from being a callback, you can use [Callback=FunctionOnly].  I was considering removing the FunctionOnly (and PropertyOnly) arguments to [Callback] so that callbacks can be implemented in script uniformly, though.

(In reply to comment #1)
> also make sure TimeoutHandler can be handled by this mechanism

  [Callback=FunctionOnly, NoInterfaceObject]
  interface TimeoutHandler {
    void handleEvent([Variadic] in any args);
  };

That would handle the current behaviour of most browsers not treating the object's handleEvent property as the implementation of the callback.  I think it would be good if implementations did allow this, though, for consistency.
Comment 3 Ian 'Hixie' Hickson 2008-11-25 00:03:04 UTC
I guess I can live with that, but it still seems heavy-duty to me.

I'd prefer something like:

  callback TimeoutHandler ([Variadic] in any args);

...at the top level, i.e. introducing a new type, followed by just using it as if it was a defined type.

I don't mind it being turned into an interface for languages that have no function types, but it is first and foremost a callback, not an interface, IMHO.

The { handleEvent: function() ... } thing seems like an accident to me, not something we should encourage.
Comment 4 Cameron McCormack 2008-11-25 00:23:42 UTC
(In reply to comment #3)
> I guess I can live with that, but it still seems heavy-duty to me.

It's really only heavy duty in the sense that it takes a few more characters to type.

> I'd prefer something like:
> 
>   callback TimeoutHandler ([Variadic] in any args);
> 
> ...at the top level, i.e. introducing a new type, followed by just using it as
> if it was a defined type.

I've been reluctant so far to introduce features that are syntactically incompatible with OMG IDL.

> I don't mind it being turned into an interface for languages that have no
> function types, but it is first and foremost a callback, not an interface,
> IMHO.

It's an interface that user code needs to implement to be called back, no? :)

> The { handleEvent: function() ... } thing seems like an accident to me, not
> something we should encourage.

But that is how DataGridProvider is expected to be implemented.  I'd prefer that regardless of the number of operations on a callback interface it be implementable using properties, for consistency.
Comment 5 Ian 'Hixie' Hickson 2008-11-25 01:10:39 UTC
DataGridProvider isn't a callback, so... :-)

Anyway, I can live with the current syntax.
Comment 6 Maciej Stachowiak 2010-03-14 13:14:43 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.