Why can't a static member be reached through the instance name?

say that I have:

class Test { public static int Hello = 5; } 

This obviously works:

  int j = Test.Hello; 

But why does this not work?

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

An instance cannot have the same member name, so I don’t see how this can be ambiguous or unsolvable for the compiler.

Does anyone know why this is?

EDIT: Is there any other technical reason why it should be different than language developers choosing this for readability / clarity / aesthetics, etc.?

+6
compiler-construction c # static
source share
5 answers

Another angle:

Suppose it was possible. What would you like the result to be when the static member is accessed through an instance variable that is null ? I would like to exclude the null reference (but why, since an instance is not required to get a static member)? Or would you like it to work (in this case, you would have a strange situation where some calls to this instance variable worked, and some did not)? In any case, there are problems.

+14
source share

Remember what static methods (or properties or fields): they apply to the class, and not to any specific instance of this class. Because of this, they are separated in all copies.

Therefore, it is logical that static members must be accessed through the class name, and not through the object. It is true that C # could have been designed differently in this regard ... but it was not.

+11
source share

I consider this a defensive language: if you mistakenly declare a property as static and then set / get it from different instances when you consider it to be an instance property, you can get all kinds of evil side effects without any really obvious indication that it’s wrong .

In order for the developer to use the class name to access the static property, he makes it clear that he is not an instance property and requires that the developer be explicit when coding, that they really want to access it as a static property.

+1
source share

"Is there any other technical reason why it should be different than language developers choosing it for readability / clarity / aesthetics, etc.?"

The only reason I can think of this is because it creates extra hoops for your compiler to transition (and not because it causes a lot of concern). If calls to static methods could be accessed by instances, the instances would have to store all the static offsets, or the compiler would have to perform an additional step in which he looked for a static method with the same signature in the class when he could not find a non-static method for the instance.

+1
source share

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

As long as the class instance contains a separate copy of all the fields of the class instance, there is only one copy of each static field.

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

As for the ambiguity of names, it can be as simple as collisions of names in something, for example, with a symbol table. However, a deeper technical review could be easily obtained.

0
source share

All Articles