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
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).
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120327/04adb8b8/attachment-0001.html>


More information about the es-discuss mailing list