Sdk: Shallow copy of object

[DartBot]

_This issue was originally filed by [e-mail]_

---

What steps will reproduce the problem?

It seems to be unnecessary difficult to create a shallow copy of an object (please correct me if I am wrong). I couldn't find another way than to implement a method copy() in each subclass of a class hierarchy that would only call its own constructor to create a new object of the same type and with the same field values.

What is the expected output? What do you see instead?

I see that a copy() method in Object might not be desirable, but it would be very useful if Dart somehow had the possibility to create a new instance of an object with identical field values (shallow copy, clone).

What version of the product are you using? On what operating system?

Dart SDK version 7904

[madsager]

_Added Area-Language, Triaged labels._

[gbracha]

_Removed Area-Language label._
_Added Area-Library label._

[lrhn]

I'd rather avoid having extra-linguistic ways to create an object (i.e., creating an object without calling a generative constructor). A clone method is exactly that.
Also, shallow copying isn't generally safe. It can lead objects to share otherwise private data structures, so it's only something that makes sense for objects that are actually prepared for it.

In other words, you shouldn't be able to clone an object of a class that isn't explicitly written for it.

So, if you want to write your classes for cloning, I do suggest giving them all

  Foo.clone(Foo original) : super.clone(this), ... 

constructors, and perhaps a copy method on each class that calls the constructor on the same type.

Most standard types where cloning makes sense (e.g., Set, List, Map) will eventually have some sort of copy constructor.

[DartBot]

_This comment was originally written by [e-mail]_

---

I agree with your argument that objects not prepared for cloning shouldn't support the operation.

I dismissed the solution you propose in my initial issue report: My problem is that I am having a huge hierarchy of classes that all must support copying. Having to implement extra constructors and copy methods in each of these classes seems to be a lot of work, add a lot of unnecessary boilerplate, and might be the cause of subtle bugs.

Ideally I would like to be able to add a single copy method to the root of my class hierarchy and let it deal with all of the sub-classes. And sub-classes would only need to override, if they actually copy some of their state. Maybe having reified classes (Issue #3368) would solve this issue as well?

[DartBot]

_This comment was originally written by [e-mail]_

---

I've been bitten on a number of occasions by the 'operator= creates a reference not a copy' issue. Coming from JS, that's expected. Coming from C++, it's not. Having an explicit way to perform a deep copy of an object rather than a reference to it would help a class of developers avoid really subtle bugs.

An example: A naive implementation of debug drawing in dartbox2d created local Vectors that were set to the position of objects using operator=. Drawing would change that position causing objects to unexpectedly move when certain debug drawing flags were enabled. In this case, the Vector has an existing constructor that copies the internal data. I think there should be a more general solution for this.

A 'clone' method on Object, for example, that must be overridden if operator= is overridden. Or a change to the semantics of the language such that operator= performs a deep copy and =& creates a reference to the object.

I prefer the latter as that's how my brain works, however I understand it would be a significant change.

[lrhn]

I don't think there is any chance of Dart changing how objects are referenced or passed as arguments. In this respect, Dart is firmly in the same camp as, e.g., Java and ECMAScript. Objects have identity, and you can only pass around references to them. There is no implicit copying.

[lrhn]

We have no current plans to make it easy to clone objects from the outside.
The objects must themselves provide the functionality, since they are the only ones that fully understand their internal invariants.

---

_Added NotPlanned label._

[kevinvandenbreemen]

I would have to agree with the language developers' assessment here. I too am looking for a solution to automagically copying Dart objects for my own project. However after reading this and investigating something called "Mirror" (see https://stackoverflow.com/questions/17021327/how-do-i-get-all-fields-for-a-class-in-dart ) I came to the same conclusion.

I might have to write a bit more code but it'll be a heck of a lot easier to debug issues than contending with a reflective copying mechanism as well.