Cloning Objects

[trezise]

Hey guys,

A while back I was looking for a way to clone certain (reference type) objects. Some classes such as the DataTable have a Clone method, but this doesn't to be the case for all classes in the Framework.

Is there a reason for this, and is it likely to change in future versions? I'm a bit of a noob, so maybe there's something I'm missing :o

Cheers

[techgnome]

Not everything is clonable. Sometimes it doesn't make sense to make a particular class clonable... take an integer for example. Doesn't really make sense to make that clonable. Then again, that's a simplistic view, not to mention that an integer is a value item, and not a reference item. As the developer, when you create class, it's up to you to determine if an object can be cloned, and how.

-tg

[penagate]

As a rule of thumb, stuff that's serialisable is generally cloneable, and vice versa.

[trezise]

I understand that not every class should be clonable, namely value types. But surely every reference type should be? Why just the serialisable ones?

[wossname]

You can make deep copies of many things by using Binary Serialization to a memory stream and then deserializing it out again into another variable. Assuming the NotSerialised attribute has not been used to prevent this of course.

[AlekseyTs[MSFT]]

I understand that not every class should be clonable, namely value types. But surely every reference type should be?

In many cases, cloning can not be done by simply copying the content of an object because it wouldn't be the right thing to do. There is an obvious question of whether it should be a deep or a shallow copy. Also, cloning is likely to lead to sharing of resources and only author of the type has the knowledge about what would the sharing mean and how it should be handled, if supported at all. So, it is up to the author to decide whether cloning feature should be available and how exactly it is going to be implemented.

Thanks,
Aleksey Tsingauz,
VB.NET Compiler Dev Team.

[Shaggy Hiker]

To take that a bit farther, there actually is a default clone:

Dim a as New <some type of class>
dim b as <same type of class>

b=a

That is a type of cloning known as a shallow copy. Wossy mentioned a rough VERY deep copy, which could have been implemented as a default clone option for most reference types.

Therefore, you have two possible "default" options. Which one is correct? One? The other? or none of the above? MS opted for the shallow copy as the default, and left it up to you to decide what level of deeper copy you would implement.

The variation on this question that I have long wondered is why there isn't a copy constructor pattern similar to that found in C++. You can sort of make one, but not really. Since many people here would be familiar with the C++ copy constructor, why not extend it into VB?