Axel Rauschmayer axel at rauschma.de
Sat Jan 11 08:52:42 PST 2014

>> 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
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140111/44d70f27/attachment.html>

More information about the es-discuss mailing list