why can't a static member be reached through an instance name?

Question

say I have:

 class Test
 {
      public static int Hello = 5;
 }

This obviously works:

 int j = Test.Hello;

But why should this not work?

 Test test = new Test();
 int j = test.Hello;

The instance could not have a member equally named, so I don't see how this could be ambiguous or unresolvable for a compiler.

Anyone any idea why this is?

EDIT: Is there any other technical reason why this should be OTHER than the language designers choosing this for readability/clarity/aesthetics/etc?

Answer 1

Remember what static methods (or properties, or fields) are: They belong to a class, and not to any particular instance of that class. Because of that, they are shared across all instances.

Therefore, it is only logical that static members must be accessed via the class name and not through an object. It's well true that the C# language could have been designed differently in this respect... but it wasn't.

Answer 2

Another angle:

Suppose this were possible. What would you then like the result to be when a static member is accessed through an instance variable which is null ? Would you like a null reference exception (but why, since no instance should be required to obtain a static member)? Or would you like it to work (in which case you would have the odd situation that some invocations on this instance variable worked, but some didn't)? Either way has problems.

Answer 3

You can read the detailed explanation of the static keyword on MSDN but I think it is best explained by this quote

While an instance of a class contains a separate copy of all instance fields of the class, there is only one copy of each static field.

I believe this might be routed in memory addresses and offsets used by the compiler. From what I remember in my compiler course in school the location of your instance variables would be stored as offsets from the first memory location where the object is stored. Since there is only one copy of the static field it would never be a fixed offset to access the value of the static field.

Regarding the ambiguity of the names, this might be as simple as name collision within something such as a symbol table. However, there could easily be deeper technical consideration.

Answer 4

I think of it as defensive language design: if you mistakenly declare a property as static, and then are setting/getting it from various instances when you assumed it was an instance property, you could get all kinds of evil side effects without any really obvious indication of what's wrong.

By requiring the developer to use the class name to access the static property, it makes it clear that it is not an instance property, and requires the developer to be explicit when coding that they really did want to access this as a static property.

Answer 5

"Is there any other technical reason why this should be OTHER than the language designers choosing this for readability/clarity/aesthetics/etc?"

The only other reason that I can think of would be that it creates extra hoops for your compiler to jump through (not that this is a huge concern). If static method calls could be accessed by instances, the instances would have to be storing all the static offsets or the compiler would have to perform an extra step where it looked for a static method with the same signature on the class when it was unable to locate a non-static method on the instance.