Enumerability

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Jan 11 09:24:05 PST 2014


I would like to see some Rick or David example about the "expected to be
enumerable".

If that's about knowing if a class is native or not, looping with a for/in
its prototype or any instance does not seem to mean anything reliable since
even native methods can be redefined and made enumerable.

If that's the case I would rather consider a simple
`Object.isNative(generic)` proposal that would simply return true for all
native things that would return `[native code]` via
{}.toString.call(generic)

enumerability does not seem to help anyone if not forcing developers
believe that every for/in loop should have a `.hasOwnProperty()` check so
that methods should be discarded, as well as shared data properties.

I am basically asking for a real-world example, if possible, where
prototype methods/properties enumerability is neede/wanted/expected, thank
you.

Best Regards




On Fri, Jan 10, 2014 at 2:10 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Jan 10, 2014, at 11:49 AM, Brendan Eich wrote:
>
> Axel Rauschmayer wrote:
>
> * Built-in prototype methods are non-enumerable, as is property `length`
> of arrays.
>
>
> Good, more consistency with existing objects.
>
> * In ECMAScript 6, prototype methods created by classes are enumerable,
> the prototype method `constructor` is non-enumerable (as it is by default
> in all functions).
>
>
> This may be a mistake. Prototype methods defined in JS are enumerable up
> to ES5 unless you use Object.defineProperty. Prototype methods on builtins
> are not enumerable. Something has to give.
>
>
> The ES6 class specification originally made  prototype methods (we didn't
> have static methods at the time) non-enumerable.
>
> That was changed at the Sept 19, 2012 TC39 meeting
> https://mail.mozilla.org/pipermail/es-discuss/2012-September/025231.html
>
> # Concise Method Definition, Revisited
>
> RW: Defaulting concise methods to non-enumerable is a mistake
>
> DH: Not sure about the decision to go non-enumerable. Users expect that
> things they create to be enumerable and things that the platform provides
> to be non-enumerable.
>
> LH: enumerability is not a real concept with any sort of meaning.
>
> EA: (reveals the broken-ness of the DOM)
>
> No longer arguable.
>
> **Conclusion/Resolution**
> Concise method definitions create [[Enumerable]]: true
>
> I went along with the majority, although I don't really like it very much.
>
> It's basically a question of whether class definitions follow the pattern
> of pre-ES6 built-in or the pattern of pre-ES6 manually constructed
> constructor/prototype pairs.
>
> Early on we decided to follow the built-in pattern, but at that meeting we
> changed it WRT enumerability of methods.
>
> It comes down to this
>
> class C extends Array {
>    foo() {}
> }
>
> let c = {foo() {}}
>
> let assignedClass = Object.assign({ }, C.prototype);
> let assignedObjLit = Object.assign({ }, c);
>
> original class design:
>   typeof assignedClass.foo   //Undefined
>   typeof assignedObjLit.foo  //Undefined
>
> current ES6 spec:
>   typeof assignedClass.foo   //function
>   typeof assignedObjLit.foo  //function
>
> another plausible design:
>   typeof assignedClass.foo   //Undefined
>   typeof assignedObjLit.foo  //function
>
> Allen
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140111/7b9374a8/attachment.html>


More information about the es-discuss mailing list