classes and enumerability

Boris Zbarsky bzbarsky at
Tue Dec 23 22:27:52 PST 2014

On 12/23/14 8:49 PM, Brendan Eich wrote:
> On the DOM quirks point

Here's the thing.  Ignoring for the moment the classes situation, it 
seems to me that for "DOM" stuff specifically we have three options:

1)  Have all "DOM" prototype stuff be enumerable.  This leaves us in a 
Conway's Law situation where whether stuff is enumerable or not depends 
on whether the spec is written by the W3C/WhatWG or TC39.  That's where 
we've been for going on two decades now, but it still sucks.

2)  Have some "DOM" stuff (whatever is currently shipping?) enumerable 
but new stuff not enumerable (basically introduce a 
[LegacyEnumerableProperties] or whatnot in Web IDL and sprinkle it on 
everything currently shipping).  This still means we have inconsistent 
behavior, but now it's inconsistent in time as opposed to organizational 
structure.  And it relies on UAs being able to make this change quickly 
for new APIs they add.  Gecko can do that, but I can't speak for others.

3)  Try to make all "DOM" stuff non-enumerable, dealing with compat 
issues by adding [LegacyEnumerableProperties] in the few cases where 
they arise.  This risks landing us in the same place as #2 depending on 
how many interfaces need the annotation, plus compat fallout as we 
discover which interfaces need it.  But it would maybe get us to the 
point where we don't have the Conway's Law problems, and it may well 
turn out that very few interfaces need the [LegacyEnumerableProperties] 

If I were doing green-field implementation of the DOM, of course, option 
3 it would be, to match ES builtins....

Apart from all that, we've generally been aiming at converging Web IDL 
behavior on the behavior of ES6 classes as much as we can, and continue 
to do so.  So if classes end up with stuff non-enumerable by default 
that would militate in favor of option 3 above.  Which is great except 
for the possible compat fallout.  I'm game for trying it, though, if 
other UAs are.


More information about the es-discuss mailing list