Дизайн Языка C#: группа метода внутри 'является' оператором
Я интересен в некоторых проектных решениях языка C#. Существует правило в спецификации C#, которая позволяет использовать группы метода в качестве выражений is оператор:
class Foo {
static void Main() { if (Main is Foo) Main(); }
}
Условие выше всегда является ложью, как говорит спецификация:
7.10.10 Оператор
• Если E является группой метода или пустым литералом, того, если тип E является ссылочным типом или nullable типом, и значение E является нулевым, результатом является ложь.
Мои вопросы: что является целью/точкой/причиной позволить использовать элемент языка C# без представления во время выполнения в CLR как группы метода в таком операторе "во время выполнения" как is?
2 ответа
какова цель / точка / причина разрешения использовать элемент языка C # без представления среды выполнения в CLR, как группы методов внутри такого оператора «среды выполнения», как is?
Язык В архиве проектных заметок не упоминается, почему было принято это решение, поэтому любое предположение об ответе будет лишь предположением. Они действительно упоминают, что если результат «есть» может быть статически определен как всегда истинный или ложный, то он должен быть определен таким образом и выдавать предупреждение. Кажется правдоподобным, что это могло быть просто ошибкой.
Самая распространенная причина превращения того, что по праву может быть ошибкой, в предупреждение (или просто разрешения), заключается в том, что это снижает нагрузку на производителей программ, которые автоматически генерируют код. Однако я не вижу здесь действительно убедительного сценария.
ОБНОВЛЕНИЕ:
Я только что проверил спецификацию C # 1.0. В нем нет этого языка. Он ничего не говорит о значениях NULL или аргументах группы методов. И, конечно, ничего не говорится о преобразованиях групп методов, потому что в C # 1.0 не было неявных преобразований групп методов; вам нужно было явно вызвать «new D (M)», если вы хотели преобразовать метод M в делегированный тип D.
Этот последний пункт является оправданием того, что «M is D» возвращает false, а не true; Вы не можете юридически сказать «D d = M;» так почему же «M is D» должно быть истинным?
Конечно, в C # 2.0 это имеет меньше смысла, поскольку вы можете сказать «D d = M;» в C # 2.0.
Я также только что спросил одного из присутствующих, когда был разработан оператор «is», и он не помнил, чтобы когда-либо решал этот вопрос так или иначе.Его подозрение заключалось в том, что первоначальная конструкция оператора is заключалась в том, чтобы не выдавать никаких ошибок, а только предупреждать, и что весь текст в спецификации о том, что делать с группами методов, значениями NULL и многим другим, был добавлен постфактум для Версия спецификации C # 2.0 и основанная на том, что фактически делал компилятор.
Короче говоря, похоже, что это была дыра в дизайне C # 1.0, которую замаскировали, когда спецификация была обновлена для C # 2.0. Не похоже, что это конкретное поведение было желательным и преднамеренно реализованным.
Эта теория подкрепляется тем фактом, что анонимные методы действительно выдают ошибку при использовании в качестве аргумента для «is» в C # 2.0. Это не было бы критическим изменением, но это было бы критическим изменением, которое заставило бы "M is D" внезапно начать возвращать истину или быть ошибкой.
ДАЛЬНЕЙШЕЕ ОБНОВЛЕНИЕ:
Изучая это, я узнал кое-что интересное. (Для меня.) Когда функция была первоначально разработана, дизайн должен был разрешить либо имя типа, , либо объект Type в качестве правого аргумента для «is». Однако от этой идеи отказались задолго до того, как появился C # 1.0.
Прежде всего, метод не является типом, msdn четко заявляет следующее:
Оператор is
используется для проверки является ли тип времени выполнения объекта совместим с заданным типом
Пример
public static void Test (object o)
{
Class1 a;
if (o is Class1) {}
}
Выражение is оценивается как истинное, если выполняются оба следующих условия:
- выражение не равно нулю.
- выражение может быть преобразовано в тип. То есть выражение приведения формы (типа) (выражение) завершится без выдачи исключения. Для получения дополнительной информации см. 7.6.6 Выражения приведения.
Итак, причина того, что ваш пример является ложным по второй точке, заключается в том, что он должен быть приведен к определенному типу.
Надеюсь, я правильно понял вопрос.