Here's what I've seen: Implementing ICloneable allows clients to learn about type "clonablility" at runtime without resorting to reflection to find a constructor that looks like a copy constructor.
ICloneable cloneableFoo = foo as ICloneable; The implementations of IClonable.Clone that I've seen [all 3 of them :)] use either Object.MemberwiseClone if it's simple or a copy constructor to tweak what is actually copied. So I guess a copy constructor can be considered an implementation detail of a cloneable type? Jim > -----Original Message----- > From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED]] On Behalf Of Jesse Liberty > Sent: Wednesday, August 14, 2002 6:02 AM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Copy constructor vs. ICloneable > > Is there a good design reason to favor implementing ICloneable rather than > implementing a copy constructor? > > -j > ------------------------------- > Jesse Liberty, President > Liberty Associates, Inc. > .NET Programming and Training > http://www.LibertyAssociates.com > > > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
