- From: Brendan Eich <brendan@mozilla.org>
- Date: Mon, 05 Nov 2012 11:01:17 -0800
- To: David Bruant <bruant.d@gmail.com>
- CC: Alex Russell <slightlyoff@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-web-security@w3.org, Webapps WG <public-webapps@w3.org>, Erik Arvidsson <arv@chromium.org>, John Messerly <jmesserly@google.com>, Jacob Richman <jacobr@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
David Bruant wrote: >> This M.O. is exacerbated by the reality that most of the folks >> writing these specs are C++ hackers, not JS developers. For many, >> WebIDL becomes a safety blanket that keeps them from having to ever >> think about the operational JS semantics or be confronted with the >> mismatches. > Interesting. I wasn't aware of that. > Any idea as to how to improve the state of things? It seems to be much > more a human problem than a WebIDL problem. Even if WebIDL improves, > people will likely still do the copy/paste dance, no? What Alex describes is inherent in having any IDL language between native implementations and JS clients. Going through the exercise Alex advocated earlier for testing API completeness, of implementing using JS instead of C++, is one way to try to overcome this problem. Boris and probably others have experience here, since Proxies in ES6 allow implementation where JS without Proxies was insufficient. We could get rid of WebIDL and specify interfaces only in JS, but without enough declarative forms that is too abstraction-leak-prone and high-overhead. Beating on WebIDL with the JS stick seems like the way to go. /be P.S.: Kudos to Alex, Arv, et al. for fighting the good fight!
Received on Monday, 5 November 2012 19:01:55 UTC