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.

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.

+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.

I know TypeScript chaps will hate me for such idea

[1] https://github.com/WebReflection/circular-json#circularjson

Regards


On Fri, Jan 10, 2014 at 12:58 PM, Claude Pache <claude.pache at gmail.com>wrote:

>
> Le 9 janv. 2014 à 12:21, Axel Rauschmayer <axel at rauschma.de> a écrit :
>
> > I’m still really unhappy about enumerability in ECMAScript. I find it
> frustratingly inconsistent:
> >
> > * At the moment, only Object.keys and the for-in loop are affected by it.
> > * In ECMAScript 6, Object.assign will also ignore non-enumerable
> properties.
>
> 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.
>
> > * Built-in prototype methods are non-enumerable, as is property `length`
> of arrays.
> > * 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).
> >
> > I’ve seen various explanations for what enumerability is:
> >
> > 1. Something that won’t matter in the long run. But then why are we
> introducing new constructs that take it into consideration?
> > 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.
> > 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?
> > 4. A way of marking a method as private. Again: why the divergence
> between built-in methods and user-defined methods?
> >
> > 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.
>
> —Claude
>
> _______________________________________________
> 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/20140110/047323c1/attachment.html>

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.

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.

+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.

I know TypeScript chaps will hate me for such idea

[1]: https://github.com/WebReflection/circular-json#circularjson