What are the design reasons to forbid accessing static elements of the class via object

Question

I cannot emphasis this more -- design reasons.

In C++ you could get static element using class (type) reference or object (instance) reference. In C# only the type reference. The more I write in C# the more problems it causes -- there are simply moments (again and again) that all I have is object, and in order to to avoid problem with lack of type (and thus access to static element) by creating regular element which passess values back and forth to static element.

One can say, that creating regular (non-static) element within a class to work as proxy for static element is small price, but I don't get for what actually I am paying. The burden is obvious for me, not critical, but annoying, so what are the benefits?

What are the design reasons, in C# you cannot reference static element of the object (from outside of course)?

Code sample

public class Foo
{
   public static readonly string Name = "name";
}

...

Foo foo = new Foo();

and now consider "Foo.Name" against "foo.Name";

Example of real case

One of the most used class for me is associative array (my custom class) for enums -- AssocEnum. It is like Dictionary but all keys are prefilled. On top of it I have classes like EnumBit (which is AssocEnum) and EnumNames (which is AssocEnum). Unlike Dictionary every instance of give enum has the same Keys property. Which means you could get Keys for AssocEnum type and for its instance.

What bothers me is the fact I have to introduce two properties TypeKeys (for class) and Keys (for instance--which is just a proxy of TypeKeys) just because I cannot call static TypeKeys for instance of AssocEnum.

Answer 1

IMO the "design reason" here is, in part, related to making intent obvious. Here's a classic example:

Thread someOtherThread = GetAnotherThread();
someOtherThread.Sleep();

now; which thread just went to sleep? Thread.Sleep() is a static method; it only ever impacts the current thread. But our code has suggested (quite incorrectly) that we called a method relating to a specific instance (someOtherThread).

It would have been entirely possible to design the language to allow it to resolve static methods; that is trivial - so it is absolutely an intentional design choice, rather than a technical limitation.

As another example:

Control someControl = GetSomeRandomControl();
someControl.CheckForIllegalCrossThreadCalls = false;

our code suggests we have made a change to disable cross-thread checks for a specific object; but that is incorrect. We have actually impacted all controls, since CheckForIllegalCrossThreadCalls is a static member.

Thus:

Thread.Sleep():

and:

Control.CheckForIllegalCrossThreadCalls = false;

are far clearer in terms of expressing what they do.