Why is TimeSpan not a typedef of Int64?

Question

System.TimeSpan class only has one non-static private field and that is

internal long _ticks;

So it only keeps ticks and performs all operations (Add, Subtract, TotalSeconds ...) and overloads operators (>=, >, ==) based on that private field, _ticks.

I see that there was no exception methods in .NET 1.0 but TimeSpan was already there but cannot it be redesigned as an alias of Int64 and other members implemented as extension methods? This way the memory footprint would be less right?

(Same applies for Url class?) Any thoughts?

Answer 1

Well, for one thing there is no equivalent of TYPEDEF in C#, so it would make Timespans incredibly difficult to work with.

TimeSpan provides a whole bunch of useful properties and methods, like .TotalHours that wouldn't make sense on an Int64, so simply making it an alias of Int64 wouldn't make much sense.

Also, I'm not entirely certain that there would be a significant (if any) difference in the class's footprint. TimeSpan is a struct, which means it will probably be implemented to have roughly the same footprint as its component pieces (in this case an Int64). (Can anybody help me find a reference to back up this impression?)

Besides that, saying that a TimeSpan is exactly the same thing as a long is just unintuitive and wrong. It increases the chance of error, where people pass a long into a parameter that should be a TimeSpan, and vice versa. Conceptually, it really goes against the grain of object-oriented programming.

I'm sure if I thought long enough about it, I could think of half a dozen other reasons (like preventing future improvements on the TimeSpan class that involve the introduction of another field, etc.), but these are probably more than sufficient.

Answer 2

Well, C# doesn't have typedef's, though you can alias a type, but that's irrelevant. If TimeSpan were simply an Int64, then what, they should create a static TimeSpanHelper class with all of the methods and properties that TimeSpan exposes?

That seems silly when you can just create a type which actually functions as a time span. A type which can override operators to allow for fluid and intuitive usage. A type which, you know, fits in well with C#'s type system. What you propose is more akin to C than C#.