W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: IDL: number types

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 25 Mar 2013 10:50:23 +0000
Message-ID: <CADnb78hPwKTTfPouD1kci-GMLg4vfVzFch80fCX5e+itHnuHvA@mail.gmail.com>
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.

Received on Monday, 25 March 2013 10:50:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC