<div dir="ltr">I hope this won't be considered spam and slightly OT but you can already happily serialize with an enumerable parent via reviver and serializer functions or simply using CircularJSON [1] which seems to be ideal for your very specific case so that you don't have to do anything once deserialized in order to have exactly same structure back.<div>
<br></div><div>I mostly agree with Axel, specially on the "class" side. I have a redefine utility that indeed defines by default all class properties and methods not enumerable since *own* property is usually what matters, the class should not affect for/in at all as we expect with any other native class.</div>
<div><br></div><div>+1 for non enumerable by default ... class are a new thing in any case, these could desugar to Object.defineProperties in the class prototype instead of simply assigning them.</div><div><br></div><div>
I know TypeScript chaps will hate me for such idea</div><div><br></div><div>[1] <a href="https://github.com/WebReflection/circular-json#circularjson">https://github.com/WebReflection/circular-json#circularjson</a><br></div>
<div><br></div><div>Regards</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 10, 2014 at 12:58 PM, Claude Pache <span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 9 janv. 2014 à 12:21, Axel Rauschmayer <<a href="mailto:axel@rauschma.de">axel@rauschma.de</a>> a écrit :<br>
<div class="im"><br>
> I’m still really unhappy about enumerability in ECMAScript. I find it frustratingly inconsistent:<br>
><br>
> * At the moment, only Object.keys and the for-in loop are affected by it.<br>
> * In ECMAScript 6, Object.assign will also ignore non-enumerable properties.<br>
<br>
</div>You forgot an important fact: While legacy `for/in` loop takes inherited properties into account, all newer constructs are only affected by *own* enumerable properties. You also forgot to mention `JSON.stringify`, which also takes only own enumerable properties into account. I guess that, in the long run, enumerability will be really significant for own properties only.<br>

<div class="im"><br>
> * Built-in prototype methods are non-enumerable, as is property `length` of arrays.<br>
> * 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).<br>
><br>
> I’ve seen various explanations for what enumerability is:<br>
><br>
> 1. Something that won’t matter in the long run. But then why are we introducing new constructs that take it into consideration?<br>
> 2. Something that one has to do properly so that old code doesn’t break. Here, it’d be helpful to be concrete: where can this happen? The obvious case is for-in for instances of built-in constructors.<br>
> 3. Signaling an intent of sharing. But what does that mean in practice? Why are built-in methods different from user-defined methods in this regard?<br>
> 4. A way of marking a method as private. Again: why the divergence between built-in methods and user-defined methods?<br>
><br>
> 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.<br>

><br>
<br>
</div>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:<br>

<br>
    obj = { foo: 1, bar: 2, children : [ { foo: 5, bar: 4 }, { foo: 2, bar: 4, children: [...] } ] }<br>
<br>
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,<br>

<br>
* I can happily invoke `Object.keys` on a node, and it will give me back the correct answer;<br>
* 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;<br>

* etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
—Claude<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br></div>