>> I think it would really help the design of ECMAScript going forward if we
>> had a definitive and complete explanation of what enumerability is now and
>> what it should be in the future. I’m trying to make sense of it and to
>> explain it to others and continue to fail.
>
> I can't provide a definite abstract explanation, but here is a practical
> situation where I've found non-enumerability a useful feature, although it
> does not exactly fit any of the four explanations you cited. Consider some
> tree structure:
>
> obj = { foo: 1, bar: 2, children : [ { foo: 5, bar: 4 }, { foo: 2, bar: 4,
> children: [...] } ] }
>
> When walking through such a tree, I typically want to have access (for
> example) to the parent of a node (just like the `parentNode` method of `Node`
> objects in the DOM). For that end, I define a *non-enumerable* `_parent`
> property on each node, which refers back to its parent node. Now, although I
> have polluted each node with a supplementary property,
>
> * I can happily invoke `Object.keys` on a node, and it will give me back the
> correct answer;
> * I can happily serialise my tree using `JSON.stringify`, and it won't
> complain that it can't handle cyclic structures. After deserialising it with
> `JSON.parse`, I just have to recursively reconstruct the `_parent`
> back-references;
> * etc.
Nice example. Data versus meta-data, in line with the `length` of an array
being non-enumerable.
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
