- From: James Graham <jgraham@opera.com>
- Date: Fri, 10 Jul 2009 22:27:05 +0000
Quoting Kartikaya Gupta <lists.whatwg at stakface.com>: > Really, it's not that much work to make sure the API can have > bindings in other languages. As long as you can write WebIDL for it > (and provide relevant DOM feature strings wherever necessary), you > should get it for free. I would also argue that considering other > languages forces you to think more about how the API may be (ab)used > and therefore results in a better and more robust API, even if it > is never actually implemented in other languages. It's not about whether it is a lot of work; it's about whether the API matches the typical programming style and feature set of the target language. Where this doesn't happen (as in much of the DOM), the API ends up feeling clunky and difficult to use. My experience with dom-equivalent APIs that have been designed to fully take advantage of the target language capabilities is that they are much more pleasant to use than the equivalent DOM APIs. Indeed one of the first things that most javascript libraries do is replace most of the DOM with their own API. This hardly seems like a ringing endorsement of the design strategy that gave us the DOM. I don't think it is sensible to optimise for the few people for whom the cross-language* approach is convenient at the expense of the many or whom it is bad. Sadly it seems that canPlayType is going to be another hacky-feeling API because of cross-language considerations and because the problems with it were not picked up soon enough :( *I idly note that DOM seems entirely unsuited to some languages so it is only really cross-language to the extent that it can be implemented in any language where you can mimic the style of java.
Received on Friday, 10 July 2009 15:27:05 UTC