Generic ICloneable

[Guest]

I'm working with Clone() for the first time, and noticed that you have to
unbox the Clone of an object that implements ICloneable:

MyObject var1 = new MyObject(); // Where MyObject implements ICloneable
MyObject va3 = (MyObject)var1.Clone();

Does anyone know why the 2.0 framework doesn't include a Generic
implementation of the ICloneable interface?

 

[Nicholas Paldino [.NET/C# MVP]]

Nathan,

If you had a generic IClonable interface, it would be something like
this:

public interface IClonable<T>
{
public T Clone();
}

If you had this, you would have to indicate what T is on your type, like
so:

public class MyClass : IClonable<MyClass>

Now, at first glance, this seems fine, but in reality, it creates a
problem. If you want to create a clone for an object, you literally have to
know to cast your instance to IClonable<MyClass>. This kind of doesn't make
sense for IClonable, since theoretically, you could define your class like
this:

public class MyClass : IClonable<MyOtherClass>

Which in the end, doesn't make sense. Granted, IClonable doesn't give
you any guarantees that the type will be the same as the class it is
implemented on, but the generic interface version doesn't do anything to
guarantee it either.

That being said, I think the designers decided to err on the side of
caution.

Hope this helps.

 

[Nick Hounsome]

I think that what you were trying to say was that if you can cast to
ICloneable<X> then the object should be an X and you can cast directly to
that and call a non-interface method.

Also the OP talked about boxing which only occurs for structs so any object
implementing ICloneable<MyStruct> would have to be a MyStruct because you
cannot derive from a struct making it even more useless than for classes
where you could at least use ICloneable<MyBaseClass> sensibly to clone an
instance of MyDerivedClass in a slightly more type safe way.

IMHO the best way to implement ICloneable is as follows:

public class X : ICloneable
{
public X Clone() { ... }
object ICloneable.Clone() { return Clone(); } // This calls the above
}

This works very well with intellisense as if you have an X it gives you the
strongly typed method not the interface method.

Nathan,

If you had a generic IClonable interface, it would be something like
this:

public interface IClonable<T>
{
public T Clone();
}

If you had this, you would have to indicate what T is on your type,
like so:

public class MyClass : IClonable<MyClass>

Now, at first glance, this seems fine, but in reality, it creates a
problem. If you want to create a clone for an object, you literally have
to know to cast your instance to IClonable<MyClass>. This kind of doesn't
make sense for IClonable, since theoretically, you could define your class
like this:

public class MyClass : IClonable<MyOtherClass>

Which in the end, doesn't make sense. Granted, IClonable doesn't give
you any guarantees that the type will be the same as the class it is
implemented on, but the generic interface version doesn't do anything to
guarantee it either.

That being said, I think the designers decided to err on the side of
caution.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm working with Clone() for the first time, and noticed that you have to
unbox the Clone of an object that implements ICloneable:

MyObject var1 = new MyObject(); // Where MyObject implements
ICloneable
MyObject va3 = (MyObject)var1.Clone();

Does anyone know why the 2.0 framework doesn't include a Generic
implementation of the ICloneable interface?