скалогрыз писал(а):неудобно, наверное, работать с объектом, в котором ничего нельзя поменять?
Как обычно, есть как плюсы, так и минусы. В зависимости от ситуации.
скалогрыз писал(а):Соглашусь - Игры и GUI приложения случаи крайне редкие.
Случаи, когда в рамках создания GUI приложений нужно создавать много объектов в секунду крайне редкие. И с GUI'евостью никак это не связано.
С играми сложнее. В больших играх такое может понадобиться.
скалогрыз писал(а):Доказательство, того, что приведённый мною ранее код неправильный и работать не будет.
этот?
- Код: Выделить всё
function BuildStampWithSomeData(const Title, Data: string; Price: double): TStamp;
begin
Result:=TStamp.Create;
Result.Title:=Title;
...
end;
Вы продолжаете утверждать, что в момент, когда результат этой функции присваивается какой-либо переменной в вызывающем коде, все поля свежесозданного класса гарантировано инициализированы?
скалогрыз писал(а):Облегчу твою задачу, Мираж. Программу я написал (прикладываю к сообщению)
Смело проверяй! ищи ошибки, с точки зрения синхронизации.
Доказывать корректность Ваших программ, оставляю Вам. Мы говорили о приведенных в топике отрывках.
А в программе, уверен, Вы учли то, о чем мы здесь говорим.
скалогрыз писал(а):Со своим уставом в чужой монастырь?Ладно.
Не понял причем тут это.
скалогрыз писал(а):Java Specs 17.5 писал(а):The usage model for final fields is a simple one: Set the final fields for an object in that object's constructor; and do not write a reference to the object being constructed in a place where another thread can see it before the object's constructor is finished. If this is followed, then when the object is seen by another thread, that thread will always see the correctly constructed version of that object's final fields.
Действительно, нужно позаботится о синхронизации передачи ссылки на объект (что в принципе очевидно), т.к. само поле никакой защиты не предоставит.
Вы забыли упомянуть, что заботиться о синхронизации нужно в пределах конструктора. Вы часто раздаете ссылки на объект из конструктора, т.е. до завершения конструктора?
После завершения конструктора ссылки можно передавать без какой-либо синхронизации.
скалогрыз писал(а):Вот так. Нужно написать ImmutablePosition и для него билдер (соответственно)
Зачем же так передергивать? Или Вы все же не понимаете концепции immutable объектов.
Если у вас есть в объекте position, который надо менять, то никакой это уже не immutable объект. Не дергаемся и делаем все mutable.
Если нужен immutable, то и position должен быть immutable.
Не говоря уже о том, что билдер для такого простого объекта как position в любом случае не понадобится.
скалогрыз писал(а):Для полноценной реализации Immutable-объектов, ему понадобится Immutable пара (для поточного использования)- ImmutablePosition.
Ввести immutable копии мутабельных объектов для многопоточного использования может быть неплохой идеей.
Билдеры для этого не понадобятся, т.к. immutable копии можно создавать, передавая в конструктор mutable оригинал.
скалогрыз писал(а):Ладно. Читаем Java устав дальше:Java Specs: 17.5.3. Subsequent Modification of final Fields писал(а): Final fields can be changed via reflection and other implementation-dependent means.
О.о. коту под хвост. Хитрые программист начнут втихушечку переписывать значение "ручками" через reflectionКомпилятор же за ними теперь не уследит!
Ну, таким способом можно и гарантии, скажем, цикла FOR отправить коту под хвост.
Reflection используют редко, и обычно зная, что делают.
скалогрыз писал(а):Как следствие, приведённый в уставе пример с "Aggressive Optimization of final Fields", конечно, из области извращений.
Но ведь кто знает, что там люди могут понаписать, а как итогJava Specs: 17.5.3. Subsequent Modification of final Fields писал(а):..., the compiler is allowed to reorder the reads of x and the call to g freely. Thus, new A().f() could return -1, 0, or 1.
Один и тот же код компилируется по разному, в зависимости от настроения комплиятора.
Этот пример тоже про использование reflection.
Да, кривыми руками можно все испортить.
Но это не повод отказываться от immutable классов, или цикла FOR.
скалогрыз писал(а):А вот в Паскале (опять же пока-что) нету ключевых слов указывающих на межпоточное взаимодействие переменных, таких как volitle в Си, или тот же final в Jave.
По-этому, ВСЯ синхронизация ложится на хрупкие плечи программиста, что имеет свои явные плюсы, т.к. код работает предсказуемо.
Предсказуемо код работает в обоих случаях.
Просто для ручной синхронизации надо знать много неочевидных вещей. И писать немало кода этой самой явной синхронизации.
Кстати, немного ниже Вы против того, чтобы писать много кода.
Final поля штука полезная, но сложная в реализации.
А вот отсутствие volatile оправдать сложнее. В Java оно конечно тоже есть. Эмулировать его вручную то еще удовольствие.
скалогрыз писал(а):Ну конечно я не понимаю.
Мне говорят, что писать мало кода - это плохо, нужно писать много (и муторно) дополнительного кода, а в чём улучшение не говорят, но ссылаются на статью на модном сайте, перевода модного автора.
Улучшение-то в чём? Безопаснее? вовсе нет.
Про то, что мало кода - плохо, никто не говорил.
Где много кода Вы пытаетесь выдумать, но плохо получается. Есть только код билдера, который не всегда нужен.
Корректную альтернативу этому "много кода" Вы не предоставили.
