Classes: Enumerability of methods and constructor
John J Barton
johnjbarton at johnjbarton.com
Tue Mar 27 08:25:01 PDT 2012
On Mon, Mar 26, 2012 at 10:38 PM, Brendan Eich <brendan at mozilla.com> wrote:
> It's your point about no data properties in the vtable, or the flip side
> of it. The for-in loop was meant to enumerate built-ins' expando and (in a
> few cases, ES3 made this more random) data-but-not-function-valued
> properties, not methods.
> It is indeed a just-so story, but the idea is that built-ins have
> intersting data properties (predefined and possibly user-defined) but the
> methods are not "interesting" to for-in users.
However, if we now look at the role of for-in in JS code, we have to
conclude that its behavior on built-ins is a bug. for-in enumerates 'all'
properties of objects; for-in/keys() are critical parts of JS reflection.
Any exceptions (eg __proto__) should be exceptional. That behavior should
extend to classes (and builtins, enumerators of expandos can easily skip
Excluding data properties from [[Prototype]]
1) avoids a serious, difficult to debug data-sharing foot gun problem,
2) has several simple alternatives.
These are the same criteria we should apply to non-enumeration.
Preventing for-in or Object.keys enumeration of classes avoids what? Has
We do have a problem among for-in/keys() and enumeration: we do not have
good solutions to separately enumerate functions (methods) and data. That
is the problem. Solving this problem be willy-nilly non-enumeration of
methods is not a good path. Ok maybe willy-nilly is a bit strong ;-)
> John J Barton wrote:
>> I appreciate understanding why this choice.
>> (FWIW, I totally don't get why non-enumerable even exists).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss