- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 29 Jan 2015 21:50:25 -0500
- To: Yehuda Katz <wycats@gmail.com>
- CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
OK, let's just cc public-script-coord here too. For those just joining in: the question is whether Web IDL prototype members should be enumerable given that TC39 just decided that inline-declared methods on classes are not enumerable in ES6. On 1/29/15 9:45 PM, Yehuda Katz wrote: > Right, but that's precisely your point about API predictability. We > shouldn't mix and match based on whether we can get away with it, or > nobody will have any idea what to expect. I think that depends on where we can manage to draw the boundary. For example, drawing the boundary at "APIs that go to CR after March 15, 2015" or some such is ridiculous because no web developer should need to care about that. On the other hand, drawing it at "Stuff on nodes is enumerable, stuff on everything else is not enumerable" is something I could at least live with (though there are complications here around EventTarget). The more complicated the description of what is and isn't enumerable, the worse it is, of course; an actual list of just "whatever we managed to get away with" is no good as you say. -Boris P.S. In case I hadn't mentioned it before, there are already UA inconsistencies in what's enumerable right now; e.g. in some UAs toString on various DOM things with stringifiers is not enumerable.
Received on Friday, 30 January 2015 02:50:55 UTC