Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

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  

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.


Received on Friday, 25 September 2009 00:56:14 UTC