Если какой-то объект сложно собирается или большая часть его функциональности вызывается конструкторами,
то методы, вызываемые только из конструктора не могут устанавливать неизменяемые поля экземпляра.
если разрешить компилятору делать это методам с атрибутом [init] это позволит обойти эту проблему.
при этом разумеется со стороны компилятора должен быть контроль: такой метод может вызываться из
конструктора или [init] метода. может уже есть подобный или альтернативный механизм?
Здравствуйте, _Claus_, Вы писали:
_C_>Если какой-то объект сложно собирается или большая часть его функциональности вызывается конструкторами, _C_>то методы, вызываемые только из конструктора не могут устанавливать неизменяемые поля экземпляра. _C_>если разрешить компилятору делать это методам с атрибутом [init] это позволит обойти эту проблему. _C_>при этом разумеется со стороны компилятора должен быть контроль: такой метод может вызываться из _C_>конструктора или [init] метода. может уже есть подобный или альтернативный механизм?
Это ограничение рантайма. Обойти его можно только инлайня функции в конструктор. Что не имеет особого смысла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
_C_>Если какой-то объект сложно собирается или большая часть его функциональности вызывается конструкторами, _C_>то методы, вызываемые только из конструктора не могут устанавливать неизменяемые поля экземпляра. _C_>если разрешить компилятору делать это методам с атрибутом [init] это позволит обойти эту проблему. _C_>при этом разумеется со стороны компилятора должен быть контроль: такой метод может вызываться из _C_>конструктора или [init] метода. может уже есть подобный или альтернативный механизм?
Неизменяемые поля можно изменять в конструкторе, если объект собирается сложным образом то стоит подумать например о паттерне Builder. Назначение конструктора собирать объект из входных данных, чтобы объект создавать более сложным образом: можно в статических методах, которые будут производить действия и вызывать конструктор с результирующими данными. На этот случай можно сделать макрос наподобие Record, который генеририрует конструкторы для разных наборов полей. Или делать конфигурационные объекты которые будут хранить всю нужную информацию для создания объекта из них, а сами они будут собираться сложным образом. Или же вообще все выносить из класса в отдельную процедуру собирания объекта, которые будут изменять состояние объекта через вызовы методов, которые порождают новый объект с измененными свойствами, это тоже можно делать макросом.
VD>Это ограничение рантайма.
согласен!
VD>Обойти его можно только инлайня функции в конструктор. Что не имеет особого смысла.
Смысл имеет, но вот конструкторов может быть несколько, и дублировать инлайновые функции — не очень хорошо.
поэтому и вижу выход в таком усовершенствовании, которое побочным эффектом имеет лучшее понимание архитектуры.
VD>Это ограничение рантайма.
я предположил, что можно обойти ограничение. если это стандартные поля InitOnly, и инструкции инлайн-подстановки в описании метода не предусмотрено, тогда нет.