'CompanyName. Нечто' является 'пространством имен', но используется как 'тип'

как мне пометить Эрика Липперта?

Если вы хотите привлечь мое внимание к чему-то, вы можете использовать ссылку «контакт» в моем блоге.

Я до сих пор совершенно не понимаю, почему компилятор C # пытается проверять конфликты между пространствами имен и типами в контекстах, в которых нет смысла для существования пространства имен.

Действительно, правила здесь хитрые. По совпадению, две недели назад я написал и разместил в блоге серию статей о некоторых из этих проблем, тесно связанных с этой самой проблемой; они действительно выйдут в эфир в начале марта. Подробности смотрите в блоге.

ОБНОВЛЕНИЕ: упомянутые выше статьи находятся здесь:

http://blogs.msdn.com/b/ericlippert/archive/tags/namespaces/

Почему возникает эта ошибка?

Разрешите перефразировать вопрос в нескольких вопросах.

Какие разделы спецификации оправдывают возникновение этой ошибки?

Я думаю, что это уже удовлетворительно освещено в других ответах. Алгоритм разрешения типов очень хорошо определен.Но просто подведем итог: нахождение внутри чего-то от правильного имени «связывает более крепко», чем , использование чего-то от правильного имени из снаружи . Когда вы говорите:

using XYZ;
namespace ABC.DEF
{
    class GHI : DEF { }
}

это то же самое, что

using XYZ;
namespace ABC
{
    namespace DEF 
    {
        class GHI : DEF { }
    }
}

Итак, теперь мы должны определить значение DEF. Идем изнутри наружу. Есть ли параметр типа GHI под названием DEF? Нет. Посмотрите на контейнер. Есть ли член DEF по имени DEF? Нет. Посмотрите на контейнер. Есть ли член ABC по имени DEF? ДА . Были сделаны; мы определили значение DEF, это пространство имен. Мы открываем значение DEF до того, как спрашиваем: «Есть ли у XYZ член DEF?»

Какие принципы дизайна влияют на этот дизайн?

Один принцип дизайна: «имена означают одно и то же, независимо от того, как вы их используете ". Язык не на 100% подчиняется этому принципу; бывают ситуации, в которых одно и то же имя может использоваться для обозначения двух разных вещей в одном и том же коде. Но в целом мы стремимся к ситуации, когда когда вы видите «Foo» два раза в одном и том же контексте, это означает одно и то же. (См. Некоторые подробности в моей статье Проблема цвета , а также в моих статьях о выявлении нарушений правил «простого имени» .)

Один принцип дизайна "без возврата". Мы никогда не говорим в C #: «Я вижу, что вы использовали имя для обозначения того, что недопустимо для ссылки в этом контексте. Позвольте мне отказаться от результата привязки имени и начать все сначала, ища что-то, что может сработать.«

Более широкий принцип, лежащий в основе принципа« без возврата », заключается в том, что C # не является языком« угадывать, что имел в виду пользователь ». Вы написали программу, в которой наилучшая возможная привязка идентификатора определяет пространство имен, когда ожидался тип. . Есть две возможности. Возможность первая: вы допустили ошибку, о которой хотите, чтобы вам сообщили, чтобы вы могли принять меры для ее исправления. Возможность вторая: вы имели в виду менее надежную привязку к быть тем, который мы выберем, и поэтому мы должны угадать среди всех возможных менее хороших привязок, чтобы выяснить, какое из них вы, вероятно, имели в виду.

Это хороший принцип проектирования для таких языков, как JScript - JScript Все дело в путанице, когда разработчик делает что-то безумное. C # - не такой язык; отзывы, которые мы получаем от наших разработчиков, сообщают мне, когда что-то ломается, чтобы я мог это исправить .

Суть «без возврата» заключается в том, что он делает язык очень легче понять. Предположим, у вас есть что-то вроде этого беспорядка:

namespace XYZ.DEF
{
    public class GHI {}
}
namespace QRS.DEF.GHI
{
    public class JKL { }
}
...
using QRS;
namespace TUV 
{
  using XYZ;
  namespace ABC
  {
    namespace DEF 
    {
        class GHI { }
        class MNO : DEF.GHI.JKL { }
    }
  }
}

Разработайте базовый тип MNO. Без возврата мы говорим: «DEF - это ABC.DEF». Следовательно, GHI - это ABC.DEF.GHI. Следовательно, JKL - это ABC.DEF.GHI.JKL, которого не существует, ошибка. Вы должны исправить ошибку, указав имя типа, которое позволяет компилятору определить, какой DEF вы имели в виду.

Если бы у нас был откат, что мы должны были бы делать? Мы получаем эту ошибку, а затем возвращаемся назад. XYZ содержит DEF? Да. Содержит ли он GHI? Да. Он содержит JKL? Нет. Вернемся снова. QRS содержит DEF.GHI.JKL? Да.

Это работает , но можем ли мы логически заключить из того факта, что это работает, что это тот, который имел в виду пользователь ?

Кто, черт возьми, знает в этой безумной ситуации? У нас есть все виды хороших привязок, которые затем испортились очень поздно в игре.Идея о том, что мы наткнулись на желаемый ответ после многих тупиков, кажется весьма подозрительной.

Правильнее всего здесь не возвращаться несколько раз и пробовать все виды худших привязок на каждом этапе поиска. Правильнее всего будет сказать «приятель, наилучшее возможное совпадение для этого поиска дает бессмысленные результаты; дайте мне что-нибудь менее двусмысленное для работы, пожалуйста».

Прискорбный факт о написании языка, на котором компилятор по замыслу громко жалуется, если лучшее соответствие - это то, что не работает, - это то, что разработчики часто говорят «ну, конечно, в общем я хочу, чтобы компилятор указывал на все мои ошибки - или скорее, все ошибки моих коллег. Но в этом конкретном случае я знаю, что делаю, поэтому, пожалуйста, компилятор, делайте то, что я имею в виду, а не то, что я говорю . "

Проблема в том, что у вас не может быть и того, и другого. У вас не может быть и компилятора, который обеспечивает соблюдение жестких правил, повышающих вероятность того, что подозрительный код будет агрессивно идентифицирован как ошибочный и , разрешающий сумасшедший код с помощью эвристики компилятора, которая выясняет, «что я на самом деле имел в виду», когда вы пишете что-то, что компилятор совершенно справедливо считает неоднозначным или неправильным.

Для наглядного урока того, как многим профессиональным разработчикам не нравятся эффекты языкового дизайна, который агрессивно выявляет ошибки вместо того, чтобы предполагать, что разработчик хотел выбрать худший результат, см. в комментариях 116 к этой статье. по второстепенному и довольно неважному аспекту разрешения перегрузки :

(Обратите внимание, что я больше не отвечаю на комментарии по этой проблеме; я разъяснял свою позицию более десяти раз. Если все эти объяснения неубедительны, это потому что я не очень хорошо умею убеждать.)

И, наконец, если вы действительно хотите проверить свое понимание того, как работают правила разрешения имен в C #, попробуйте эту небольшую головоломку . Практически каждый ошибается или ошибается по неправильным причинам. Ответ здесь .