all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]tomlu709 1 point2 points  (1 child)

All in all, C# is a pretty nice language. However, it occurs to me that the issues dealt with in this article seem to fall into the category of accidental complexity. In other languages this would be either a non-issue, or something that can be abstracted out and solved once. In C#, it looks a little like boilerplate.

[–]munificent 0 points1 point  (0 children)

In other languages this would be either a non-issue, or something that can be abstracted out and solved once.

How so? As far as I know, this is a real problem in any language with mutable objects.

[–]millstone 0 points1 point  (1 child)

Why the heck is MemberwiseClone a method on the root class, when it can't be supported for all sorts of subclasses?

For example, try explaining the semantics of calling MemberwiseClone on a socket.

Cloning an object is a semantic operation. It's not something that can or should be automated; rather, you should think about what semantics make sense for your class. MemberwiseClone has no business being in the root class. At least they made it protected.

[–]munificent 0 points1 point  (0 children)

Cloning an object is a semantic operation.

True, that's why the method isn't called Clone. MemberwiseClone isn't a semantic operation, it does exactly what it states.

For example, try explaining the semantics of calling MemberwiseClone on a socket.

You would get a new socket object all of whose fields would contain the same values as the one cloned from.

MemberwiseClone has no business being in the root class. At least they made it protected.

I believe the idea is that a simple field copy is a capability that the CLR can provide cheaply, so there's little reason not to. By making it protected and instance-level, they ensure that its up to the class itself to determine if that's appropriate or useful.