John J Barton wrote:
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 ;-)
Yes, too strong. JS is already specified in detail regarding non-enumerable methods on build-on constructors' prototype properties (and for some other properties).
If classes and method definition syntax are meant to model built-ins and their proto-methods, or even if the same use-cases motivate making methods non-enumerable in both cases, then we should not start making methods enumerable.
If on the other hand classes (and arguably method definition syntax) are sugar for the user-defined prototypal pattern, pre-ES5, then all the prototype methods set by assignment will indeed be enumerable.
So again, which is the target use-case? Emulating built-ins or sugaring the user-defined prototypal pattern?
Put this way, I agree with you (and with Dave on the earlier point about C.prototype.constructor being configurable): we should pave the cowpath. Anyone wanting non-enumerability (or in the other case, non-configurability) can use ES5 meta-programing APIs.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
