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

Re: IDL: number types

From: Sam Tobin-Hochstadt <samth@ccs.neu.edu>
Date: Sat, 23 Mar 2013 15:41:47 -0400
Message-ID: <CAK=HD+biyNgStZqQu=6r3O0K+YbOpVhDd1BE0DOVJaswxiGsHA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Marcos Caceres <w3c@marcosc.com>, Yehuda Katz <wycats@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, public-script-coord@w3.org
On Wed, Mar 20, 2013 at 4:54 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/20/13 2:40 PM, Allen Wirfs-Brock wrote:

>> 1.  Web APIs should be designed first for ES.  The best way to do this is
>> to actually do an initial ES implementation and check it's usability.
> They should be designed to be _used_ from ES.  Whether they should be
> designed to be _implemented_ from ES is a separate question.

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++.

This is a point Alex has made about "pure Java" [1] in a related context.


[1] http://infrequently.org/2012/04/bedrock/
Received on Monday, 25 March 2013 08:30:39 UTC

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