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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
