classes and enumerability

Brendan Eich brendan at mozilla.org
Tue Dec 23 20:49:15 PST 2014


Jeremy Martin wrote:
> In all the discussions I've observed, the primary argument for 
> enumerability has been consistency with ES5 prototype conventions. I 
> don't think I've seen a single argument in favor, though, based on the 
> actual intrinsic merits of that behaviour.

Right, hence my tweet about "A foolish consistency". And the other tweet 
against the argument-from-it's-always-been-that-way(-in-ES3-level-JS) 
fallacy.

Even if you grant that enumerability is unreformable, we have to pick a 
"better consistency".

It seems to me that DOM quirky enumerability of prototype methods, and 
legacy ES3-ish enumerability of user-defined methods, do not sum  up to 
"better'.

I tweeted several times that the legacy ES3 and below resulting in 
enumerability for theprototypal-pattern's class prototype methods is a 
bug not a feature.

On the DOM quirks point, built-in classes and self-hosting of built-ins 
trump DOM quirks any day. Boris may have a census that argues against my 
weighting, though.

Hence my support for a last-minute fix.

/be




More information about the es-discuss mailing list