On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
> That sounds reasonable. There are really two issues. One is that
> there are parts of WebIDL that are unused. Another is that the parts
> of the spec themselves are fairly arcane and very implementor-
> specific. Consider:
>
> interface UndoManager {
> readonly attribute unsigned long length;
> getter any item(in unsigned long index);
> readonly attribute unsigned long position;
> unsigned long add(in any data, in DOMString title);
> void remove(in unsigned long index);
> void clearUndo();
> void clearRedo();
> };
>
> I almost forget that I'm looking at something most widely
> implemented in a dynamic language when I look at that. Since this is
> most likely to be implemented in terms of ECMAScript, why not
> provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure
ECMAScript, since they need to tie into the browser implementation and
system APIs. So a reference implementation in ECMAScript is not
possible.
What this interface definition actually specifies is some constraints
on how the implementation of this object is reflected to ECMAScript.
For example, this method must convert its second parameter to a string
using a particular algorithm, and the prose description of the
method's behavior assumes that has been done, and the return value
promises to be a positive integer:
unsigned long add(in any data, in DOMString title);
This method converts its one parameter to a number, and performs
truncation and range checks according to some standard rules, and will
for example raise an exception if a negative number is provided:
void remove(in unsigned long index);
It would be tedious to spell out all those details for every such
method, either in prose or in ECMAScript code - that interface
definition would be replaced by something 5-10 times as long.
Another thing to keep in mind - although ECMAScript is the primary
target language for the IDL interfaces in Web technology
specifications, it is quite common to expose these interfaces in Java,
and is desirable for various applications to be able to provide them
in languages such as Python, C++, Objective-C, and Ruby. Thus, we need
a language-independent formalism to define the interfaces, even though
the ECMAScript bindings are the most important.
And finally, even though the snippet of Web IDL you cited is very much
aimed at authors, I think it's pretty easy to understand the practical
upshot for ECMAScript programmers, without understanding the details
of Web IDL. It's pretty clear what attributes and methods you can use,
and what kind of parameters you should provide. For those who care
about the full details, you only have to learn Web IDL once, and it's
not a very big syntax. It's sort of like learning EBNF to understand
grammar definitions. The extra conciseness is worth the cost of an
extra formal syntax to learn, in my opinion.
Regards,
Maciej