Наверное все здесь присутствующие в курсе существования макры Accessor. Им вполне можно пользоваться, да только код выглядит не особенно красиво, автосвойства читать легче и удобнее — они исходят из описания интерфейса класса.
Подход Accessor-а к объявлению свойств ведет к следующим минусам:
1) настройка модификаторов видимости свойства аргументами макроса
2) невозможность вводить различные модификаторы для акцессоров (т.е.: get {...} internal set {...})
2) неудобно вешать атрибуты на свойства
Единственная фича, которая есть у Accessor-а, и которой нет у автосвойств — это возможность задать начальное значение полю.
Именно этот синтаксис хочется прикрутить к объявлению автосвойства.
Предлагается ввести следующий синтаксис (get, set, default могут идти в любом порядке) и воплотив его объявить Accessor устаревшим:
Здравствуйте, hardcase, Вы писали:
H>Предлагается ввести следующий синтаксис (get, set, default могут идти в любом порядке) и воплотив его объявить Accessor устаревшим: H>
H>public Foo : int { get; set; default = 10; }
H>
А почему бы тогда не приблизить эту запись к записи инициализаторов полей?
Foo : int = 10 { get; set; }
или
Foo : int { get; set; } = 10;
Здравствуйте, hi_octane, Вы писали:
_>Здравствуйте, hardcase, Вы писали:
H>>Предлагается ввести следующий синтаксис (get, set, default могут идти в любом порядке) и воплотив его объявить Accessor устаревшим: H>>
_>А почему бы тогда не приблизить эту запись к записи инициализаторов полей?
_>
_>Foo : int = 10 { get; set; }
_>или
_>Foo : int { get; set; } = 10;
_>
Первое будет конфликтовать с объявлением поля в indent-синтаксисе, а усложнять парсер для такой простой фичи я не вижу смысла.
И оба решения плохо выглядят в случае, если выражение инициализации будет занимать более одной строки.
Решение с { get; set; default = очень_много_закорючек } визуально ограничивает выражение инициализации.
P.S. Если же подходить к этому вопросу совсем глобально, то конечно, объявление свойства должно быть максимально простым — т.е. текущий синтаксис поля должен по сути быть объявлением свойства. А поля, если они все же необходима, объявлять c ключевым словом field.
Здравствуйте, hardcase, Вы писали:
H>объявить Accessor устаревшим:
Вот это делать не надо, так как у него все же остаются некоторые возможности (например, возможность навесить атрибуты на поле).
С остальным согласен.
ЗЫ
За одно предлагаю сделать человеческую реализацию инициализации полей. А то сейчас это делается через макроатрибут, что зачастую приводит дикой кривизне и непониманию работы компилятора.
Вообще, макросы в принципе не должны использоваться компилятором для построения АСТ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>P.S. Если же подходить к этому вопросу совсем глобально, то конечно, объявление свойства должно быть максимально простым — т.е. текущий синтаксис поля должен по сути быть объявлением свойства. А поля, если они все же необходима, объявлять c ключевым словом field.
Согласен с такой формулировкой! Может так и сделать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
P.S. Если же подходить к этому вопросу совсем глобально, то конечно, объявление свойства должно быть максимально простым — т.е. текущий синтаксис поля должен по сути быть объявлением свойства. А поля, если они все же необходима, объявлять c ключевым словом field.
Будет не хилая несовместимость с предыдущими версиями, но зато более чистое решение (синтаксис), унификация и отсутствие двуличия (ханжества). А то наличие полей, но при этом почти обязательная (причем, маниакальная и необоснованная) страсть к инкапсуляции всех полей (даже неизменяемых) в свойства меня всегда раздражала.
Много лет назад (о знакомства с Н) я уже озвучивал мысль отказа от полей. Идея по умолчанию делать свойства мне очень нравится. А модификатор field позволит решить мелкие неувязочки.
Может правда так сделать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Много лет назад (о знакомства с Н) я уже озвучивал мысль отказа от полей. Идея по умолчанию делать свойства мне очень нравится. А модификатор field позволит решить мелкие неувязочки.
VD>Может правда так сделать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>объявить Accessor устаревшим:
VD>Вот это делать не надо, так как у него все же остаются некоторые возможности (например, возможность навесить атрибуты на поле).
в C# насколько мне помниться есть примерно такой синтаксис:
class MyClass
{
[field: Description("Str")]
public int Prop {get;set;}
}
Здравствуйте, VladD2, Вы писали:
H>>объявить Accessor устаревшим:
VD>Вот это делать не надо, так как у него все же остаются некоторые возможности (например, возможность навесить атрибуты на поле).
А модификаторов атрибутов в Немерле нету, типа
[field: NotSerialized] // Атрибут будет примён к сгенерированному компилятором полюpublic Foo : int { get; set; default = 10; }
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, hardcase, Вы писали:
H>См. первое сообщение.
H>public X : int { get; default = 10 }
Здорово, если я правильно понимаю, то set-акессора в этом случае вообще не будет, даже приватного?
Это хорошо: когда инициадизатор простой, можно делать так, а когда сложный, то
H>public X : int { get; private set; }
А как на счёт ещё одного варианта: свойство, которое инициализируется строго один раз в конструкторе (например, параметром), но при этом не имеет сеттера? Синтаксически в конструкторе программист обращается к свойству, а компилятор заменяет это на инициализацию поля. Типа:
class X
{
public this(int x) {
X = x; // по факту тут запись в ридонли-поле для свойства.
}
public X : int { get; readonly set; }
}
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>А как на счёт ещё одного варианта: свойство, которое инициализируется строго один раз в конструкторе (например, параметром), но при этом не имеет сеттера? Синтаксически в конструкторе программист обращается к свойству, а компилятор заменяет это на инициализацию поля.
То что ты сейчас описал и есть get-only-свойство немерла. Именно так оно и работает. Только никаких readonly set не нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
