On Mon, Mar 26, 2012 at 10:38 PM, Brendan Eich <[email protected]> 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 functions). 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 which alternatives? 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 ;-) jjb > > /be > > > John J Barton wrote: > >> >> I appreciate understanding why this choice. >> >> (FWIW, I totally don't get why non-enumerable even exists). >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
