Почему методы расширения допускаются только в не-вложенном, неэквивалентном статическом классе?

Ответ 1

Почему методы расширения допускаются только в не-вложенном, неэквивалентном статическом классе?

Как указывает Пратик, вопрос, с которым мы сталкиваемся, не "почему методы расширения не допускаются во вложенных или общих классах?" Вопрос, с которым мы сталкиваемся как разработчики языка, - "почему следует использовать методы расширения во вложенных или общих классах?"

Если эта функция не оправдана некоторыми потребностями пользователя в реальном мире, мы не собираемся брать на себя значительные затраты на проектирование, внедрение, тестирование, документирование и поддержку этой функции.

В основном, методы расширения были разработаны для работы LINQ. Все, что не помогло сделать работу LINQ, было сокращено. LINQ требует только методов расширения в статических, не общих, не вложенных классах для работы, так что мы разработали и внедрили.

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

Бесполезно ли рассматривать методы расширения в вложенном, статическом классе generic?

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

Ответ 2

Как писал Эрик Липперт много раз в своем блоге, каждое изменение на С# тщательно оценивается по набору критериев для его оправдания и не основано только на технологии. В этом случае не требуется, чтобы LINQ был отключен для снижения риска. Проверьте этот сообщение в блоге от Эрика для аналогичного вопроса.

Ответ 3

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

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