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]
-
mv*@spam.guard.caspershouse.com
"Nathan" <Na****@discussions.microsoft.com> wrote in message
news:14**********************************@microsof t.com...
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?