Re: IDL: number types

On Mon, Mar 25, 2013 at 6:50 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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.

I think that today, you can reason about platform object in terms of
the JavaScript semantics, often by reference to the MOP.  I agree that
this is an improvement. But that doesn't guarantee that the objects
defined by the platform behave like *normal* JS objects, as opposed to
what the ES6 draft defines as "exotic objects".

My point is that to the degree that platform objects are exotic
objects in this sense, they are more surprising to programmers, and
behave less like the regular JS objects that programmers normally
encounter.

By definition, objects that are implementable in JS (without using
proxies) won't need to be exotic objects.  This is why the mere fact
that something is *implementable* matters, even if in the end nothing
gets implemented in JS.

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

This is not what I mean by implementable. The important thing is
whether a project similar to dom.js can implement a given platform
object without relying on an escape hatch such as proxies.
Participation in the particular DOM of an existing system is, as you
point out, a more complex question.

Sam

Received on Monday, 25 March 2013 14:46:22 UTC