Question

If I look at the members of the .NET type System.Version it might be a better idea to create such a type as value type (C# struct) instead of a reference type (class).

What might be the reasons or arguments that Microsoft decided to implement that type in that way? Is it simply a kind of "bug" / mistake / inconsequence or a "feature" (in other words: "really wanted and useful"?

There are methods like Parse() and TryParse() which are typical for value types, e.g. System.Int32, System.Double or System.Guid. The properties of System.Version only store short and integer values (s. System.TimeSpan), the type itself is comparable (with operators) and as struct it might not be necessary to make it cloneable.

I do not have anything against that "status quo", it is only to satisfy my curiosity ;-)

EDIT: Added comparison to System.TimeSpan.

Was it helpful?

Solution

According to Microsoft's own guidelines, you should prefer a class to a structure when the instance is at least 16 bytes. Since System.Version stores four Int32, each consisting of four bytes for a total of 16 bytes, they followed their own advice and made it a class.

OTHER TIPS

I can't say for sure, but one reason might be immutability. The properties in the Version class are all read-only. Whereas it's possible to declare readonly fields in a struct, Eric Lippert points that readonly on a struct field is a lie.

Making it a class ensures immutability.

Another point that may have been relevant in the design process is that Version is ComVisible.

As such, it makes more sense to expose it to COM as a coclass (behavior, without guarantees about internal layout) rather than as a COM struct (which specifies an in-memory layout like a C struct).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top