The Int64 Problem

Brad Notes:

“We are having a little debate internally on an issue around naming conventions for moving APIs to the 64bit world. 

We made a few design mistakes in V1 and exposed some properties that are really word sized as Int32’s rather than Int64s.  I don’t think there are very many of these, but it seems we need a common pattern for any we do dig up…

Here is an example.  On the Process class today we have:
public int VirtualMemorySize { get; }
public int WorkingSet { get; }

As you know we can’t just change these to return longs as that would break apps complied against V1 or V1.1 when run on Whidbey…  We also can not add overloads that return longs as the properties must differ by more than return type (btw, this is a CLS rule not a runtime rule, the runtime is just fine with overloading on return type.. now the only problem is finding a language where that is valid ).  So we are left we having to make a name change…“

If you are going to do this, you might as well be consistant and use Long like the 1.1 framework did.

However, I think the guys at MS are some times bozos. Why do we need all sorts of silly properties like this?

Solutions that are much more natural:

Implement a custom type called ByteLength or something will all the proper implicit/explicit conversion operators, so that it functions like an Int32 / Int64, etc. but can be upgraded at will. Isn't this type of thing why C++ programmers have been using typedefs for ages?

Make generics support something like this:

T Length<T>
{
  get;
  set;
}

Solutions that are less natural, but don't need a million upgrades and properties to work:

Put in a method called GetLength(Type retType) which returns the appropriate length.