- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 25 Mar 2013 10:50:23 +0000
- To: Sam Tobin-Hochstadt <samth@ccs.neu.edu>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Marcos Caceres <w3c@marcosc.com>, Yehuda Katz <wycats@gmail.com>, public-script-coord@w3.org
On Sat, Mar 23, 2013 at 7:41 PM, Sam Tobin-Hochstadt <samth@ccs.neu.edu> wrote: > I don't anyone has pointed out (in this thread) one of the big > benefits of making Web APIs implementable in JS -- it requires that > the objects specified that way behave like every other JS object. > Almost by definition, JS programs primarily interact with objects > created in JS, which behave in certain ways, allowing programmers to > form a hopefully-coherent model about how things work. Platform > objects can, unfortunately, end up behaving quite differently because > they are not constrainted to be implemented in JS. Constraining them > to be *implementable* in JS (more so if they avoid magic such as > proxies) fixes this, even if no one ever implements that API in > anything other than C++. I think by and large you can reason about platform objects in terms of JavaScript these days. That's pretty much what Web IDL has been about as the bindings we had before that effort described pretty much nothing. See http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html for an example of where we came from. Implementable is something else though. It seems unlikely we'll ever let someone create a node from the ground up for instance without some part being "hosted" to allow for asynchronous selector matching and such. -- http://annevankesteren.nl/
Received on Monday, 25 March 2013 10:50:55 UTC