classes and enumerability

Brendan Eich brendan at mozilla.org
Wed Dec 24 16:22:39 PST 2014


Boris Zbarsky wrote:
> 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] thing.

We aren't going to reverse-Conway the core language built-ins to have 
enumerable methods, ever -- so I think the right attack is on the quirky 
DOM. As usual :-P.

(I'm to blame for some of these quirks, IIRC -- but I don't have 
Netscape 2 or 3 code around. So, I'm to blame for everything. As usual :-|.)

Are there some DOM prototype methods/accessors that are non-enumerable? 
Sorry for the dear-lazy-bz mail.

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

Yup. This should weigh on us.

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

Hope to hear from bterlson and someone on chromium/Blink DOM/WebIDL duty.

/be


More information about the es-discuss mailing list