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 15:38:44 -0700
Cc: public-webapi@w3.org
Message-Id: <D2B3A40D-C421-4FED-B2DD-3440268D3187@apple.com>
To: Stewart Brodie <stewart.brodie@antplc.com>

On May 21, 2007, at 4:01 AM, Stewart Brodie wrote:

> "Anne van Kesteren" <annevk@opera.com> wrote:
>> On Mon, 21 May 2007 03:33:39 +0200, Cameron McCormack <cam@mcc.id.au>
>> wrote:
>>> Implementors that use the IDL to generate code for the  
>>> implementations:
>>> which would you prefer?
>> Do implementors use the IDL directly or do they modify it before  
>> using it?
>> In the latter case making the specification easier to write and  
>> read makes
>> sense to me... Implementors that have ECMAScript support can also  
>> benefit
>> as they can probably auto-generate more code if ECMAScript properties
>> becomes part of the new IDL syntax.
> We don't auto-generate anything directly from the IDL, not least  
> because of
> the sort of problems outlined earlier in this thread.  Instead, we  
> have our
> own internal XML format that serves the same purpose that we use to  
> generate
> our DOM bindings headers, to drive automatic type coercions, and to  
> build
> documentation of exactly which methods, constants, interfaces and  
> properties
> are implemented.
> There is just too much DOM0 stuff that we need to support that isn't  
> in the
> IDL in the later DOM specifications anyway.  Trying to reverse  
> engineer that
> into IDL format doesn't sound like a lot of fun.

It's totally doable if you are willing to use IDL extended attributes  
to mark up the quirks, Gecko has long done this and WebKit is now  
using it for most interfaces as well. We're not using the W3C's IDL  
files though, in either case.

And the standard W3C license for IDL files would likely make it  
impossible to start with them. If we wanted to publish IDL that  
implementors could use, we'd have to change the license.

Received on Monday, 21 May 2007 22:38:57 UTC

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