W3C home > Mailing lists > Public > public-webapi@w3.org > May 2007

Re: Method overloading in IDL

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 21 May 2007 03:41:02 -0700
Cc: public-webapi@w3.org
Message-Id: <326D63A9-8F29-4B78-B695-3099F1197EE7@apple.com>
To: Cameron McCormack <cam@mcc.id.au>

On May 20, 2007, at 7:31 PM, Cameron McCormack wrote:

> Cameron McCormack:
>> I’m starting to write some text for Bindings4DOM, and am wondering  
>> which
>> direction to take for method overloading.
> Ian suggests (in IRC) that we go for the “W3C IDL” option so that more
> ECMAScript specific functionality can go directly into the IDL.  Then
> things like whether an attribute is DontEnum or whatever could be
> specified like so:

>  interface NodeList {
>    // in Opera you can delete NodeList.prototype.item;
>    Node item(in unsigned long index);
>    // but you can’t delete NodeList.prototype.length;
>    readonly DontDelete attribute unsigned long length;

I think DOM attributes are generally DontDelete, so it would make more  
sense to note the exceptions that are deletable.

>    // define the array indexing behaviour
>    Node [[Get]](in unsigned long index);
>    // and maybe you need to give the behaviour for real property
>    // lookups (or maybe it would default to having this behaviour)
>    any [[Get]](in any propName);

I think special access by index and name should be specified on the  
interface, not as specially named methods, like

interface NodeList[IndexAccess=Item] {


BTW I think brackets are free for use by IDL extensions so we could  
use them for any extensions and still sort of be OMG IDL compatible.

>  }
> There are two targets of the bindings spec in my mind: one is spec
> writers, who want to be able to refer to the bindings spec and have
> useful definitions to make their job easier when writing specs that  
> will
> be used with ECMAScript; the other is implementors, who may use the  
> for code generation.
> Going with “W3C IDL” certainly helps the spec writers, since it means
> they can stick ES-specific things more succinctly in the IDL (at the
> expense of being less language neutral).  Would this extra information
> in the IDL (rather than in some prose in the other spec, or in the
> bindings spec that is then referenced by the other spec) help
> implementors who use the IDL for code generation?

In WebKit, we use extended attributes heavily in our IDL for code  
generation. Some are just implementation details, but others affect  
the interface. Some exceptions from our Document.idl:

interface [GenerateConstructor] Document : EventTargetNode {

         readonly attribute [ConvertNullStringTo=Null] DOMString  

	readonly attribute [ConvertNullStringTo=Undefined] DOMString  

         [ConvertNullStringTo=False] DOMString queryCommandValue(in  
DOMString command);


Notice that nominal null strings are in practice returned in at least  
3 different ways to JS (null, undefined and false), yet still other  
possibilities are returning the empty string or the string "null".  
Sometimes there are quirks to the conversion *from* JS as well, on  
input arguments or when assigning non-readonly attributes.  
GenerateConstructor means there should be window.Document and  
window.Document.prototype defined (although window.Document can't  
actually be used as a constructor with "new" in JS, it is otherwise  
similar to a global constructor object).

Things we don't have in our IDL yet are descriptions of which DOM  
attributes should be replaceable (nominally readonly but can be  
replaced with any value through a simple assignment, even ones of the  
wrong type), shadowable (can be shadowed by a "var" declaration,  
likely this applies only to Window properties) and shadowable by a  
function delcaration. I plan to do research on which of these applies  
for what Window property as part of the Window object spec. We also  
generally  treat overloading as optional arguments:

   void scrollIntoView(in [Optional] boolean alignWithTop);

I don't think this is sufficient to describe window.open or  
window.setTimeout though.

Received on Monday, 21 May 2007 10:41:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC