Здравствуйте, ·, Вы писали:
vsb>>

vsb>>var person1 = Person with {
vsb>>    lastName = l;
vsb>>    firstName = f;
vsb>>    age = 18;
vsb>>};

vsb>>var person2 = person1 with {
vsb>>    age = 16;
vsb>>};
vsb>>

·>По-моему фигня какая-то, первое — просто сахарок, который IDEA уже и так подсказывает в виде parameter hints.

Это не сахарок, это единственный способ не сойти с ума. Parameter hints у меня отключен. И код не только в IDE смотрят.

> Второе — как в scala case-class, очень неудобно, когда модификация поля порождает новый объект — жуть.

Ну, как я писал, иммутабельность это уже навсегда, мне тоже это не по нраву, но придётся с этим жить, если хочется использовать record-ы.

·>Для dto в 40 полей такое всё равно не годится. Нужен билдер, чтобы по частям можно было собирать.

Так тут по частям и можно собирать. Это просто кусок кода, в котором неявно объявлены в начале переменные, соответствующие членам записи, и из значений которых в конце неявно конструируется эта самая запись. Иными словами это сахар для

Person person2;
{
    var firstName = person1.firstName();
    var lastName = person1.lastName();
    var age = person1.age();
    // тут начинается пользовательский код
    age = 16;
    // тут заканчивается пользовательский код
    person2 = new Person(firstName, lastName, age);
}

Ну это всё пока на уровне фантазий для обсуждения было, конкретного конечного описания пока вроде не было и когда будет — не понятно.

В целом не вижу особой нужды для билдера в такой ситуации. По крайней мере не могу припомнить ситуации, где мне он был бы нужен. Ну да, возможно придётся собирать такой объект несколько раз в разных методах, там, где можно было раньше один билдер передавать. Ну такая вот цена иммутабельности, процессоры сами себя не продадут.

·>Хочется такого:
·>

·>public Person modify(Person p) {
·>  var builder = p.builder();
·>  updateAAA(builder);
·>  ...
·>  if(...) updateBBB(builder);
·>  else updateCCC(builder);
·>  ...
·>  updateDDD(builder);
·>  return builder.build();
·>}
·>

Ну да, такого не будет. тут только конструировать промежуточные объекты и передавать их в методы updateAAA и тд.

·>В принципе хорошо иметь иммутабельность, но это требует парный мутабельый билдер и всё становится сложно с т.з. дизайна ЯП.

Не знаю, я вообще не понимаю этого ограничения. Ну да, иммутабельность это хорошо, кто бы спорил. Но всему своё место. А уж в жаве, в которой испокон веков фреймворки писались для мутабельных бинов, впихивать это насильно — ну такое. Пускай и иммутабельность будет и мутабельность.

Здравствуйте, ·, Вы писали:
vsb>>

vsb>>var person1 = Person with {
vsb>>    lastName = l;
vsb>>    firstName = f;
vsb>>    age = 18;
vsb>>};

vsb>>var person2 = person1 with {
vsb>>    age = 16;
vsb>>};
vsb>>

·>По-моему фигня какая-то, первое — просто сахарок, который IDEA уже и так подсказывает в виде parameter hints.

Это не сахарок, это единственный способ не сойти с ума. Parameter hints у меня отключен. И код не только в IDE смотрят.

> Второе — как в scala case-class, очень неудобно, когда модификация поля порождает новый объект — жуть.

Как я писал, иммутабельность это уже навсегда, мне тоже это не по нраву, но придётся с этим жить, если хочется использовать record-ы.

·>Для dto в 40 полей такое всё равно не годится. Нужен билдер, чтобы по частям можно было собирать.

Так тут по частям и можно собирать. Это просто кусок кода, в котором неявно объявлены в начале переменные, соответствующие членам записи, и из значений которых в конце неявно конструируется эта самая запись. Иными словами это сахар для

Person person2;
{
    var firstName = person1.firstName();
    var lastName = person1.lastName();
    var age = person1.age();
    // тут начинается пользовательский код
    age = 16;
    // тут заканчивается пользовательский код
    person2 = new Person(firstName, lastName, age);
}

Это всё пока на уровне фантазий для обсуждения было, конкретного конечного описания пока вроде не было и когда будет — не понятно.

В целом не вижу особой нужды для билдера в такой ситуации. По крайней мере не могу припомнить ситуации, где мне он был бы нужен. Возможно придётся собирать такой объект несколько раз в разных методах, там, где можно было раньше один билдер передавать. Такая вот цена иммутабельности, процессоры сами себя не продадут.

·>Хочется такого:
·>

·>public Person modify(Person p) {
·>  var builder = p.builder();
·>  updateAAA(builder);
·>  ...
·>  if(...) updateBBB(builder);
·>  else updateCCC(builder);
·>  ...
·>  updateDDD(builder);
·>  return builder.build();
·>}
·>

Такого видимо не будет. тут только конструировать промежуточные объекты и передавать их в методы updateAAA и тд.

·>В принципе хорошо иметь иммутабельность, но это требует парный мутабельый билдер и всё становится сложно с т.з. дизайна ЯП.

Я вообще не понимаю этого ограничения. Иммутабельность это хорошо, кто бы спорил. Но всему своё место. А уж в жаве, в которой испокон веков фреймворки писались для мутабельных бинов, впихивать это насильно — ну такое. Пускай и иммутабельность будет и мутабельность.