Почему методы установки и получения свойств конфликтуют с методами get_X и set_X?

Question

В .NET свойства должны быть гражданами первого класса, однако в коде IL свойства получения и установки свойств реализованы как get_ PropertyName и set_ PropertyName .

class Property
{
    int Value { get { return 42; } }
    int get_Value() { return 6 * 9; }
    void set_Value(int i) { } // Error even though Value is a read only property
}

Выход:

ошибка CS0082: тип «SO.Property» уже резервирует элемент с именем «get_Value» с такими же типами параметров

ошибка CS0082: тип 'SO.Property' уже резервирует элемент с именем 'set_Value' с такими же типами параметров

Почему разработчики .NET решили использовать имя, которое может конфликтовать с кодом пользователя? Они могли бы использовать недопустимый символ (поскольку Java использует $ для внутреннего содержимого класса).

Answer 1

Для языков, которые не имеют понятия свойств, таких как J # (что может очень хорошо повлиять на это проектное решение), все равно необходимо иметь простое имя для их вызова.

Answer 2

Спецификация общего языка (CLS) требует использования методов get_ и set_ в IL (украшенных специальными битами) при реализации свойств. Это необходимо для того, чтобы разные компиляторы (C #, управляемый C ++, VB.NET, J #, IronPython и т. Д.) Создавали совместимые байт-коды.

Таким образом, подчеркивания являются не «законными» символами в более широком смысле. Они не совместимы с CLS и поэтому не должны использоваться в не приватных интерфейсах.

Также см. Эту статью о написании CLS-совместимого кода на MSDN.

Answer 3

Потому что их, возможно, нужно вызывать из внешнего кода.

Answer 4

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

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