What's more, even if you do find what looks like a copy constructor, you've
not actually got any guarantees that it really is a copy constructor. For
example:
public class TreeNode {
public TreeNode(TreeNode parent) { ... }
...
}
If you were using reflection to look for copy constructors, this one would
meet the requirement. But it's fairly evident from the name that this is
not in fact a copy constructor, it just happens to take a reference to a
different instance of the same type on initialization...
By contrast, ICloneable.Clone is quite unambiguous in its meaning.
(Well...ignoring the deep vs. shallow copy issues.)
--
Ian Griffiths
DevelopMentor
----- Original Message -----
From: "Graeme Foster" <[EMAIL PROTECTED]>
> 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.
>
> -----Original Message-----
> From: Jesse Liberty
>
> Is there a good design reason to favor implementing ICloneable rather than
> implementing a copy constructor?
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
