W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] [URL] DOM API Feedback

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 19 Nov 2012 11:16:23 -0500
Message-ID: <50AA5B57.7060605@mit.edu>
To: David Bruant <bruant.d@gmail.com>
Cc: whatwg@lists.whatwg.org
On 11/19/12 11:00 AM, David Bruant wrote:
>> How close are "subclasses" to not being vaporware (both in spec and
>> implementation terms)?
> I don't understand what you mean by vaporware. ES6 Maps are a reality in
> Firefox and Chrome (behind a flag for the latter).

Yes, I know that.

> Subclassing of ES6
> maps will be possible as soon as ES6 classes do (which I admit are still
> unimplemented)

Yes, that's what I mean by "vaporware".  ;)

> ... well... it's actually possible today with __proto__ I guess.

Is it?  It's not terrible possible for arrays, right?  Have we checked 
that it is for maps?

> It's still possible for the spec to define an API that maps (no pun) the
> ES6 Map API (and does some additional magic). For those who'd care
> enough, it'll be possible to make this object a map.

So... the question is whether the spec will require that this object 
"is" a Map, whatever that means.

> If not an ES6 map, the same API will be good enough to avoid API diversity.

I have no problem with "same API".  The issue is how to define this in a 
way that UAs actually end up interoperable in the end.  If some use Map 
and some don't, that's not exactly great.

> Interesting, I thought the proposal was meant to capture de facto
> standard. Did UAs converge for that behavior recently? More
> specifically, what does IE9 do? (I guess oldIE are the ones diverging
> from the others?)

All UAs agree on ordering of non-index properties.

For index properties, they don't agree in all sorts of ways.  The 
behaviors I know about:

1)  V8 enumerates indexed properties in index order always, for all
     objects, as far as I know.
2)  Spidermonkey enumerates indexed properties on "fast" arrays (the
     ones that have no non-index props and don't have too many holes,
     and some other conditions) in index order.  In all other cases it
     enumerates them in set order, where set order when an array
     transitions from "fast" to "slow" is index order.  I believe we
     plan to change this behavior to match that of V8 sometime, but the
     timeframe is many months at best.
3)  JSC enumerates indexed properties in set order on my testcase
     earlier in this thread.  I didn't experiment more, because frankly
     you can do that just as well as I can.  ;)
4)  Carakan enumerates indexed properties in index order on my small
     testcase.  Again, further experimentation is open to anyone who
     cares.

Basically, the spec here codified the de-facto standard in the case 
where there was interop (non-index properties) and just picked a random 
behavior from the wide range of available behaviors for the case where 
there was so little interop that it was clear the web didn't depend on 
any particular behavior too much (index properties).  In particular, the 
V8 behavior was picked, as far as I can tell.

-Boris
Received on Monday, 19 November 2012 16:33:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT