Re: Method overloading in IDL

* Cameron McCormack wrote:
>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:

The problem we want to solve with the ES Bindings specification is that
a number of things are not at all or only poorly specified, for example,
what happens if you pass a non-natural Number to a method that needs a
long integer Number, a Number passed to a DOMString method, how do call-
back methods work with respect to `this` object binding, how to specify
constructor functions, or which attributes like DontDelete are set for
the various things we specify.

The IDL code as it currently occurs in the DOM specification serves a
different purpose; it's there to provide an overview of interfaces,
what methods are there, which attributes, since when are they in the
DOM specifications, along with links to their individual definition;
and it is there as language neutral version of the features, you can
read the IDL code and have a pretty good idea how to use the methods
and other features in Java, Perl, ActionScript, C++, or whatever you
use.

Adding ECMAScript specific details to it would make them more difficult
to read and less language neutral, again making it more difficult to
read if you are not actually writing code in ECMAScript. Further, the
examples you give below, like DontDelete or some CanDelete are not use-
ful even if you do write code in ECMAScript, except perhaps for a few
nerds. As such I do not agree mixing the two things. It's possible that
using some kind of formal language to define the ECMAScript bindings is
a good idea, such a language might even be derived from IDL, but such
things would go into an ECMAScript-specific appendix.

>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.

Some implementers have already settled on using the .xml sources rather
than the IDL code generated from them for code generation purposes; and
the few that use IDL in some form in their implementations are not like-
ly to significantly benefit from such changes, it's about as easy to
write the code they need by hand or through copy and paste and adapting
it as it would be to write and adapt tools to use such features. At the
moment they would be better served by a specification as outlined above.

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

I do not think this would help either group. What could be useful would
be extensions for the current .xml format and the pre-processors we are
using; then it would be relatively simple to generate whatever you need
directly from them, as some implementers are already doing. Certainly it
would make the specification less readable to have ES-specific things in
the IDL code.

As for overloading, I do not think this is a problem that needs any form
of solution in this version of the ES Bindings specification. I would
suggest to look at that once we have a draft that addresses the problems
I have discussed above.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 22 May 2007 12:55:31 UTC