clone function does not act as before

[lodash]

clone function does not act as before

[jdalton]

@adrai Thanks for reporting. This is one of the reasons I released as RC because I wanted to check the usage of _.clone with objects created from non-Object constructors.

So the docs for _.clone state that

Functions, DOM nodes, arguments objects, and objects created by constructors other than Object are not cloned unless they have a custom clone method.

I don't clone objects created from non-Object constructors because it wouldn't be cloning the inheritance and instead would flatten it to a vanilla object. The workaround would be to add a Wrappy.prototype.clone to ensure inheritance but it looks like by your usage that you really needed _.extend({}, ...).

I could make shallow clones, not passing deep, of objects flatten but I wanted to keep it consistent for the initial RC and see what issues it ran into in real code.

[jdalton]

I could make shallow clones, not passing deep, of objects flatten but I wanted to keep it consistent for the initial RC and see what issues it ran into in real code.

cc'ing @kitcambridge @mathiasbynens for opinions on shallow clone of objects that don't have Object as their constructor vs deep clone.

[Raynos]

@jdalton https://gist.github.com/3300375

[jdalton]

@Raynos that ES5 approach still misses things that may have been set or processed in the constructor call. The easiest cross-browser consistent way is to punt and allow the dev to implement their own clone method that then _.clone will use.

[Raynos]

@jdalton of course. You also can't clone closures. I think a sensible default for an object with a prototype is that clone function.

Of course my own opinion is that I never use clone. I use new Constructor(instance.toJSON()) for any of my serialization / deserialization logic

[jdalton]

of course. You also can't clone closures. I think a sensible default for an object with a prototype is that clone function.

Nope, I'm going for ES3 support too.

Of course my own opinion is that I never use clone. I use new Constructor(instance.toJSON()) for any of my serialization / deserialization logic

Which is doable with _.clone if you implement it on:

Constructor.prototype.clone = function() {
  return new Constructor(this.toJSON());
};

Underscore's current behavior is to do _.extend({}, source) internally. I'm trying to gauge if devs actually use _.clone on object created from non-Objected constructors.

[jdalton]

I'm also considering allowing a callback argument that _.clone can use for normally non-cloned values without them having to have a clone method,

[adrai]

@jdalton Your are right, in this case i need _.extend({}, ...).
For me it's ok...
You make a good job! :-)

@jdalton

cc'ing @kitcambridge @mathiasbynens for opinions on shallow clone of objects that don't have Object as their constructor vs deep clone.

Definitely deep clone. I also like the idea of being able to pass a callback function to clone.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.