classes and enumerability
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.
More information about the es-discuss