Re: Removal of identifierless getters, setters, etc.

On Oct 13, 2010, at 11:30 PM, Ian Hickson wrote:

> 
> We know what happens when people take the IDL design for JS and apply it 
> to other languages: we get what happened when people wrote IDL for Java 
> and applied it to JS, namely, a poorly-designed API. IMHO, WebIDL 
> shouldn't be language agnostic. There should be a specific IDL provided 
> for each language supported. In some cases they might be very similar, but 
> simply taking the JS one and using it elsewhere is not good practice.

WebKit has a single set of IDL files that are used to produce not only a JavaScript mapping, but also Objective-C, C++, C using Gtk's GObject model, Python, and perhaps other languages in the future.

Sometimes this produces quirky results . However, JavaScript is seen as the primary binding. The goal for other language bindings is not to produce a binding that is the most elegant match for that language, but rather, to faithfully match the JavaScript bindings and to provide a complete mapping of all Web APIs.

Your proposal of inventing a new IDL for each target language would not be a good fit for this model, and in particular the ad-hoc changes to specific APIs that you suggested in the rest of your message would not work very well. Here are some significant downsides:

(1) A major goal for non-JavaScript mappings of the DOM is matching the JavaScript mappings, so that developers can reuse documentation and acquired knowledge. Ad-hoc differences in APIs would significantly hurt this goal. On the whole, this would outweigh the benefit of a slightly more elegant API for the particular language. It's ok that DOM APIs won't seem totally idiomatic in other languages.

(2) Having separate IDL for each target language is not scalable. If we had to invent a new dialect of IDL, create a full set of new IDL files, and accept ongoing maintenance of these parallel IDL files, then it's likely none of the language bindings I mentioned would exist. The barrier to entry and the ongoing maintenance burden would be too high. That would be a shame, because I think developers using WebKit have benefitted significantly from DOM bindings for alternate languages. In fact, I would say that different IDL per target language defeats the whole purpose of IDL, which is to define an interface once, and then be able to map it to multiple languages in a systematic way.

Thus, based on actual working experience with this sort of thing, I think your suggestion would work out very poorly in practice, even if it seems to have more theoretical purity. It would be worse for browser engine implementors, and worse for developers who make use of browser engines in their applications.

Regards,
Maciej

Received on Thursday, 14 October 2010 06:52:55 UTC