W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: classes and enumerability

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Thu, 29 Jan 2015 21:50:25 -0500
Message-ID: <54CAF171.2050000@mit.edu>
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC