c# - Why is it useful to access static members "through" inherited types? -

i'm glad c# doesn't let access static members 'as though' instance members. avoids common bug in java:

thread t = new thread(..); t.sleep(..); //probably doesn't programmer intended. 

on other hand, does let access static members 'through' derived types. other operators (where saves writing casts), can't think of cases helpful. in fact, actively encourages mistakes such as:

// nasty surprises ahead - won't throw; unintended: // creates httpwebrequest instead. var ftprequest = ftpwebrequest.create(@"http://www.stackoverflow.com");  // wrong here. var arerefequal = dictionary<string, int>.referenceequals(dict1, dict2); 

i keep committing similar errors on , on when searching way through unfamiliar apis (i remember starting off expression trees; hit binaryexpression. in editor , wondering why on earth intellisense offering me makeunary option).

in (shortsighted) opinion, feature:

1. doesn't reduce verbosity; programmer has specify type-name 1 way or (excluding operators , cases when 1 accessing inherited static members of current type).
2. encourages bugs/ misleading code such 1 above.
3. may suggest programmer static methods in c# exhibit sort of 'polymorphism', when don't.
4. (minor) introduces 'silent', possibly unintended rebinding possibilities on recompilation.

(imo, operators special case warrant own discussion.)

given c# "pit of success" language, why feature exist? can't see benefits (other 'discoverability', solved in ide), see lots of problems.

i'd agree misfeature. don't know how on stack overflow has posted code of:

asciiencoding.ascii 

etc... which, while harmless in terms of execution misleading in terms of reading code.

obviously it's late remove "feature" now, although guess c# team introduce super-verbose warning mode , other style issues.

maybe c#'s successor improve things...