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 <[email protected]>wrote: > > Le 9 janv. 2014 à 12:21, Axel Rauschmayer <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
