- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 24 Sep 2009 17:55:30 -0700
- To: Yehuda Katz <wycats@gmail.com>
- Cc: Brendan Eich <brendan@mozilla.com>, public-webapps@w3.org, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
- Message-id: <0004B0FB-5899-46A9-A91C-79D0A8C62B4B@apple.com>
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
Received on Friday, 25 September 2009 00:56:14 UTC