Автоматические свойства позволяют мне заменить этот код:
private MyType myProperty;
public MyType MyProperty
{
get { return myPropertyField; }
}
с этим кодом:
public MyType MyProperty { get; private set; }
с некоторыми изменениями здесь и там - но есть ли способ заменить этот код:
private readonly MyType myProperty;
public MyType MyProperty
{
get { return myPropertyField; }
}
с чем-то похожим?
Действительно, в настоящее время это невозможно сделать.
Мы понимаем, что в C # 3 мы создали некоторый философский оксюморон. Дизайн LINQ в значительной степени пропитан традиционным неизменяемым функциональным стилем программирования - выполнение откладывается, запросы представлены неизменяемыми монадами, деревья выражений неизменны и т. Д.
И все же в то же время инициализаторы объектов, инициализаторы коллекций и автоматические свойства поощряют традиционный стиль программирования на основе изменяемых компонентов. Похоже, что мы идем в обоих направлениях, что свидетельствует о природе C #; это прагматичный язык программирования, поддерживающий множество различных стилей программирования.
Однако, поскольку мы все большие поклонники неизменного стиля программирования и верим, что этот стиль принесет дивиденды, упростив обеспечение корректности многопоточных приложений в будущих повсеместных многоядерных архитектурах, мы определенно заинтересованы в поисках способа обуздать введенную нами изменчивость. Автозаполнение только для чтения - один из очевидных способов сделать это; маленький шаг, но хороший.
Тем не менее, мы еще даже не выпустили C # 4 и не объявили, что после этого появятся какие-либо новые языковые функции. Вы должны относиться ко всем моим размышлениям о гипотетических характеристиках необъявленных продуктов как к предположениям «только для развлечения», а не как к обещаниям или объявлениям.
Нет, к сожалению нет. Мне бы очень понравилась функция, которая могла бы выглядеть так:
public readonly string Name { get; }
или (немного странно)
public readonly string Name { get; readonly set; }
Это будет преобразовано во что-то вроде:
private readonly string <>_Name;
public string Name { get { return <>_Name; } }
Хитрость в том, что вызовы установщика будут разрешены, но только внутри конструктора. Такие вызовы будут преобразованы непосредственно в назначения для резервного поля.
Мне бы очень, очень понравилась такая функция. Может быть, для C # 5 ...
set, даже если свойство всегда имеет сеттер? Тем более, что сеттер может иметь разные уровни доступа, даже если он readonly (верно? Я думаю о private и protected.)
- person Blixt; 08.10.2009
private в третьем блоке кода на protected? Каким должен быть сокращенный код для такого вывода?
- person Blixt; 08.10.2009
readonly ситуация иная, поскольку к вспомогательному полю должен напрямую обращаться ваш код (после компиляции). И поскольку возможно иметь поле protected, вы можете предотвращать какой-то случай, когда protected readonly имеет смысл, только поддерживая private. Я бы тоже не стал использовать protected, но я видел случаи, когда ограничение функциональности на основе таких предположений препятствовало некоторым изящным функциям (например, where T : Enum.)
- person Blixt; 08.10.2009
readonly может применяться только к полям, поэтому я не верю.
Не могли бы вы просто использовать:
public readonly MyType MyProperty;
поскольку в любом случае он может быть назначен только из конструктора?
Нет, ты никак не сможешь это сделать. Фактически, я не понимаю, зачем вам получить значение свойства, которое не было установлено ранее. По очевидным причинам вы не можете установить значение, если нет ни set средства доступа, ни поля поддержки.
Это действительно запутанный приятель.
Просто сделайте это общедоступным полем только для чтения.
readonly, а затем оно будет заменено свойством только с общедоступным аксессором get (которое все еще может возвращать значение поля private readonly). Это нарушит двоичную совместимость.
- person Blixt; 08.10.2009
public readonly MyType MyProperty { get; private set; }сработает), но в итоге я использовал синтаксис в конце вашего вопроса. - person Blixt schedule 08.10.2009