I don't know what you'd call a good reason, but here's one that's good enough for me - it's easier to call IClonable.Clone() than it is to call a constructor for an unknown type.
Compare: object clone = ((IClonable) anyObj).Clone(); To: <pseudocode> 1. Get type of anyObj 2. Find copy constructor for that type 3. Invoke copy constructor </pseudocode> It's also easier to tell if it's supported by an object. Cheers, G. -- Graeme Foster ([EMAIL PROTECTED]) Principal Software Engineer Aston Broadcast Systems Ltd. (http://www.aston.tv) Disclaimer: I really don't have a clue what I'm on about. -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Jesse Liberty Sent: 14 August 2002 12:02 To: [EMAIL PROTECTED] Subject: Copy constructor vs. ICloneable Is there a good design reason to favor implementing ICloneable rather than implementing a copy constructor? ***************************************************************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to any one or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** ***************************************************************************** You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
