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

Re: Method overloading in IDL

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 21 May 2007 12:31:31 +1000
To: public-webapi@w3.org
Message-ID: <20070521023131.GD8134@arc.mcc.id.au>

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;

    // 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);
  }

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 IDL
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?

Thanks,

Cameron

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au
Received on Monday, 21 May 2007 02:31:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT