Deep cloning objects defined by JSON.

Mark S. Miller erights at
Sun Jan 29 10:22:02 PST 2012

Since all these candidates can be provided by libraries, this seems like an
area where libraries can explore and compete. If/once a consensus emerges
from such a competition, then we can revisit whether there's really any
reason to standardize.

If we were talking about this in time to prevent or displace html5's (IMO
horrible) "structured clone" operation, I would be much more positive about
rushing something sane through the standardization process. But we are
already too late to achieve that happy ending :(, and I see no other
adequate reason to rush this.

FWIW, I like the idea that any clone operation should be defined as
equivalent to JSON.parse(JSON.stringify(obj, ..), ..), and so I like your
suggestion of putting this on the JSON object. As for a more general
Object.clone, I agree with what I think is Allen's position: There is no
useful clone semantics/contract that applies in a uniform way across
different abstractions, and so it would be inappropriate to add such a
method to Object or Object.prototype. (Allen, apologies if I have
mischaracterized your position.)

On Sun, Jan 29, 2012 at 1:05 PM, Peter van der Zee <ecma at> wrote:

> Why can't we define a JSON.clone() or .deepClone() which would only
> clone properties that are primitives, object or array. If they are
> (instanceof) array, copy index properties and length value and create
> new array with that information. If object, create new object and copy
> all properties with the same restrictions as before.
> I suppose another discussion is whether you'd want/need to copy
> property attributes as well. For me, for at least JSON.clone, I would
> be happy with just a clone of the primitive value of a property.
> In other words, I think a JSON.clone would work as if the structure
> was first serialized to a string. The serialization would drop any
> value or property that's not primitive, object or array. Objects and
> arrays are serialized to [] and {} notation. For arrays, only index
> properties are copied (so not even length or other properties). The
> resulting string would then be deserialized by JSON.parse. Of course
> the serialization doesn't need to happen internally, but I think hope
> that makes it clear what I mean (drops all weird stuff from structures
> like getters, setters and attributes).
> By putting such a method on JSON, you leave the way open for whatever
> clone should be on Object and still have an intuitive feeling for what
> JSON.clone would probably do (opposed to Object.clone).
> Cloning functions is a dangerous sport anyways due to closures, but I
> don't think anyone would expect JSON.clone to clone functions too.
> - peter
> On Tue, Jan 24, 2012 at 7:46 PM, Rick Waldron <waldron.rick at>
> wrote:
> > non-recursive, deep clone by John-David Dalton:
> >
> >
> >
> >
> > Rick
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at
> >
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list