Почему это полезно для доступа к статическим членам "через" унаследованные типы?

Я рад, что С# не позволяет вам обращаться к статическим членам, как если бы они были членами экземпляра. Это позволяет избежать общей ошибки в Java:

Thread t = new Thread(..);
t.sleep(..); //Probably doesn't do what the programmer intended.

С другой стороны, он позволяет вам обращаться к статическим членам через "производные типы". Помимо операторов (где это избавляет вас от написания бросков), я не могу думать о каких-либо случаях, когда это действительно полезно. Фактически, он активно поощряет ошибки, такие как:

// Nasty surprises ahead - won't throw; does something unintended:
// Creates a HttpWebRequest instead.
var ftpRequest = FtpWebRequest.Create(@"http://www.stackoverflow.com");

// Something seriously wrong here.
var areRefEqual = Dictionary<string, int>.ReferenceEquals(dict1, dict2);

Я постоянно повторяю подобные ошибки снова и снова, когда я ищу свой путь через незнакомые API (я помню, как начинался с деревьев выражений, я нажал BinaryExpression. в редакторе и задавался вопросом, почему на Земле IntelliSense предлагал мне MakeUnary как вариант).

В моем (недальновидном) мнении эта функция:

• Не уменьшает детализацию; программист должен указать имя типа так или иначе (исключая операторы и случаи, когда один обращается к унаследованным статическим членам текущего типа).
• Поощряет ошибки/вводящие в заблуждение коды, такие как выше.
• Может предложить программисту, что статические методы в С# показывают какой-то "полиморфизм", когда они этого не делают.
• (Незначительный) Внедряет "безмолвные", возможно непреднамеренные возможности перезаписи при перекомпиляции.

(IMO, операторы - это особый случай, который гарантирует их собственное обсуждение.)

Учитывая, что С# обычно является языком "удачи", почему эта функция существует? Я не вижу его преимуществ (кроме "открытости", которая всегда может быть решена в среде IDE), но я вижу много проблем.

Ответы

ASCIIEncoding.ASCII