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

vsb>>·>Во-первых, неясно зачем их видеть?
vsb>>Что значит "зачем их видеть"?
·>"2 — нет и это хорошо бы видеть" — зачем видеть отсутствующий геттер-сеттер?

Я про то, что 2 — не автосгенерированы, а написаны вручную с нетривиальной логикой. И эту логику хочется видеть. Если у нас .NET с его get/set, там это прекрасно видно.

Лично я это делал так: у меня были нетривиальные методы сверху, а автосгенерированные в отдельном блоке, помеченном специальными комментариями, которые идея умеет находить и сворачивать. Но это уже костыли.

·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.

Такой подход не пробовал, я пишу руками всё, автосгенерированные классы мне не нравятся (если только я сам не писал этот автогенератор).

·>Не, record вполне готов. Туда пихать ничего лучше не надо. Если что-то добавлять для билдеров, то это пусть лучше будет какая-то другая фича.

record готов для крошечных классов вроде Point(int x, int y). Хранить там 50 полей это безумие. Пока не будет синтаксиса для создания/изменения с указанием каждого имени. Собственно этот синтакс и обещают и скорей всего он будет. Но когда — :hz:

·>В c# {get;set;} — это встроенная фича языка, а в java это реализуется библиотечно с помощью Annotation Processor, как частный случай. Поэтому нет смысла пихать какой-то новый синтаксис.

Lombok это не библиотека. Это хак, который не должен работать и когда-нибудь перестанет. И тогда придётся запускать какой-нибудь lombokc вместо javac, как и должно быть по-хорошему изначально.

vsb>>lombok это да, это единственное, что хоть как-то спасает. Но надо понимать, что lombok это ещё один язык, похожий на Java. Я бы предпочёл писать на Java, а не на lombok.
·>Согласен. Впрочем создать dto+builder+withers+toString можно при отсутствии альтернатив.

Можно, но это костыли от недостатков языка, а не нормальная ситуация.

Я не считаю, что .NET идет правильным путем, суя в язык как сорока всё блестящее. И Java делает правильно, не торопясь с фичами. С тем же async/await они торопиться не стали и правильно сделали, сейчас вырисовывается более правильное решение. Но в некоторых случаях это приводит к перегибам.

В целом я думаю, что писать на Java 25 будет вполне приятно. Но пока — не очень.

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

vsb>·>"2 — нет и это хорошо бы видеть" — зачем видеть отсутствующий геттер-сеттер?
vsb>Я про то, что 2 — не автосгенерированы, а написаны вручную с нетривиальной логикой. И эту логику хочется видеть. Если у нас .NET с его get/set, там это прекрасно видно.
vsb>Лично я это делал так: у меня были нетривиальные методы сверху, а автосгенерированные в отдельном блоке, помеченном специальными комментариями, которые идея умеет находить и сворачивать. Но это уже костыли.
А, понял. Я вообще избегаю такое. Нетривиальные геттеры-сеттеры чаще с толку сбивают, чем пользу приносят. Тем более когда их 2 из 40.

vsb>·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.
vsb>Такой подход не пробовал, я пишу руками всё, автосгенерированные классы мне не нравятся (если только я сам не писал этот автогенератор).
Суть в том, что api обычно уже имеет некое описание независимое от каких-либо ЯП. Поэтому генерить из этих описаний java-код вполне разумно. Пишешь генератор ты сам или используешь готовый — неважно.

vsb>·>Не, record вполне готов. Туда пихать ничего лучше не надо. Если что-то добавлять для билдеров, то это пусть лучше будет какая-то другая фича.
vsb>record готов для крошечных классов вроде Point(int x, int y). Хранить там 50 полей это безумие. Пока не будет синтаксиса для создания/изменения с указанием каждого имени. Собственно этот синтакс и обещают и скорей всего он будет. Но когда — :hz:
По-моему record создавали с другой целью — для pattern matching. Если что-то и сделают, то это будет какой-то другой элемент языка.

vsb>·>В c# {get;set;} — это встроенная фича языка, а в java это реализуется библиотечно с помощью Annotation Processor, как частный случай. Поэтому нет смысла пихать какой-то новый синтаксис.
vsb>Lombok это не библиотека. Это хак, который не должен работать и когда-нибудь перестанет. И тогда придётся запускать какой-нибудь lombokc вместо javac, как и должно быть по-хорошему изначально.
Не скажу за весь lombok, но по-моему геттеры-сеттеры можно генерить используя вполне себе стандартный annotation processor.

vsb>>>lombok это да, это единственное, что хоть как-то спасает. Но надо понимать, что lombok это ещё один язык, похожий на Java. Я бы предпочёл писать на Java, а не на lombok.
vsb>·>Согласен. Впрочем создать dto+builder+withers+toString можно при отсутствии альтернатив.
vsb>Можно, но это костыли от недостатков языка, а не нормальная ситуация.
Ну если недостаток языка покрывается библиотекой, основанной на стандарте языка, то это наоборот — достоинство. Вместо всяких хитрых хотелок есть механизм для реализации произвольных хотелок.

vsb>Я не считаю, что .NET идет правильным путем, суя в язык как сорока всё блестящее. И Java делает правильно, не торопясь с фичами. С тем же async/await они торопиться не стали и правильно сделали, сейчас вырисовывается более правильное решение. Но в некоторых случаях это приводит к перегибам.
java как в том анекдоте про двух быков: "мы медленно-медленно спустимся с горы...".
Проект медленно пишется и годами поддерживается большими командами.
А если надо быстро-быстро бежать, то есть всякие груви котлины и скалы.

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

vsb>В жаве в 2022 году нужно генерировать геттеры и сеттеры.

В 2022 уже не надо, см. https://docs.oracle.com/en/java/javase/14/language/records.html

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

vsb>>В жаве в 2022 году нужно генерировать геттеры и сеттеры.

scf>В 2022 уже не надо, см. https://docs.oracle.com/en/java/javase/14/language/records.html

Я в курсе. Это пока не юзабельно.

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

·>По-моему record создавали с другой целью — для pattern matching. Если что-то и сделают, то это будет какой-то другой элемент языка.

Там будет что-то вроде

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

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

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

·>Не скажу за весь lombok, но по-моему геттеры-сеттеры можно генерить используя вполне себе стандартный annotation processor.

Я сам не пробовал annotation processor-ы писать, поэтому могу ошибаться. Но в моём понимании annotation processor может генерировать либо полностью новый класс, который старый код видеть не будет. Либо какие-то там проверки делать и тд. То бишь максимум, который можно сделать оставаясь в рамках того, что разрешено — руками объявить interface Person { String name(); String name(String name); }, а annotation processor сгенерирует class PersonImpl implements Person { ... } и ты его экземпляр уже как-то получишь.

А как lombok делает — так нельзя делать.

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

scf>В 2022 уже не надо, см. https://docs.oracle.com/en/java/javase/14/language/records.html
Угу. Им бы ещё value-типы, настоящие дженерики, Expression Trees, query comprehensions, и паттерн-матчинг.
И тогда, может быть, из джавы и удастся выпилить хоть что-то приемлемое для потребления в 2022 году.

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

S>Угу. Им бы ещё value-типы, настоящие дженерики, Expression Trees, query comprehensions, и паттерн-матчинг.

value-типы — перфоманс-вкусовщина, ненастоящие дженерики всех устраивают, про expression trees и query comprehensions я и не слышал, а паттерн-матчинг завезли. Не скаловский, конечно, но ADT можно рисовать.

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

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. Второе — как в scala case-class, очень неудобно, когда модификация поля порождает новый объект — жуть.
Для dto в 40 полей такое всё равно не годится. Нужен билдер, чтобы по частям можно было собирать.

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

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

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

vsb>·>Не скажу за весь lombok, но по-моему геттеры-сеттеры можно генерить используя вполне себе стандартный annotation processor.
vsb>Я сам не пробовал annotation processor-ы писать, поэтому могу ошибаться. Но в моём понимании annotation processor может генерировать либо полностью новый класс, который старый код видеть не будет. Либо какие-то там проверки делать и тд. То бишь максимум, который можно сделать оставаясь в рамках того, что разрешено — руками объявить interface Person { String name(); String name(String name); }, а annotation processor сгенерирует class PersonImpl implements Person { ... } и ты его экземпляр уже как-то получишь.
Ты прав. Можно только новый тип создавать оказывается.

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

scf>value-типы — перфоманс-вкусовщина
А то. Вот то ли дело escape-analysis
scf>ненастоящие дженерики всех устраивают
Ну, за отсутствием value-типов — могу согласиться.
scf>про expression trees и query comprehensions я и не слышал
А зря. Очень рекомендую. Правда, есть риск: после linq2db смотреть на Hibernate будет очень грустно. Ну, и перформанс-плюс-сейфети вкусовщину вроде https://github.com/evilguest/linq2d не выпилишь.

scf>а паттерн-матчинг завезли. Не скаловский, конечно, но ADT можно рисовать.
Что, прямо уже можно объединять PM с deconstruction? сразу получая штуки типа

  var s = switch(o) {
    case Manager(Assistant(var assistantName, var assistantEmail), var name, var position) -> $"{position} : {name} (contact {assistantName} via {assistantEmail} to schedule a meeting}";
...

? Круто, молодцы парни, быстро идут вперед. Ещё недавно нельзя было.

Здравствуйте, ·, Вы писали:
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 и тд.

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

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

Здравствуйте, ·, Вы писали:
·>По-моему фигня какая-то, первое — просто сахарок, который IDEA уже и так подсказывает в виде parameter hints. Второе — как в scala case-class, очень неудобно, когда модификация поля порождает новый объект — жуть.
·>Для dto в 40 полей такое всё равно не годится. Нужен билдер, чтобы по частям можно было собирать.

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

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

А что там внутри этих updateBBB()?
Почему нельзя просто сделать тот же With? Ведь при присванивании "в себя же" ескейп-анализ уберёт всю лишнюю нагрузку на GC, в итоге имеем тот же перформанс, лаконичный синтаксис, и отсутствие необходимости для каждого DTO еще и цельный билдер расписывать.


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

·>Ты прав. Можно только новый тип создавать оказывается.
Переходите на сторону CLR. У нас всё это есть Включая "annotation processors"

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

S>? Круто, молодцы парни, быстро идут вперед. Ещё недавно нельзя было.

https://blog.jdriven.com/2022/10/pattern-matching-in-java-19/

Завезли пару месяцев назад. Да и то — большинство боится использовать последнюю версию и предпочитают сидеть на LTS, следующий будет через год примерно. Я даже скажу, что большинство боится использовать последний LTS и предпочитает сидеть на предыдущем LTS Поэтому он вроде как есть, но скорей в будущем.

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

S>А что там внутри этих updateBBB()?
Там ещё могут быть простыни кода, ведь у нас 40 полей которые надо по всякому вычислять и проставлять. Если модификация p происходит очень сложно, то хочется это всё разрезать на мелкие кусочки по разным методам или даже классам, иногда даже реюзабельным из разных мест.

S>Почему нельзя просто сделать тот же With? Ведь при присванивании "в себя же" ескейп-анализ уберёт всю лишнюю нагрузку на GC, в итоге имеем тот же перформанс, лаконичный синтаксис, и отсутствие необходимости для каждого DTO еще и цельный билдер расписывать.
Как я понял, ты предлагаешь что-то вроде

public Person modify(Person p) {
  p = updateAAA(p);
  ...
  if(...) p = updateBBB(p);
  else p = updateCCC(p);
  ...
  p = updateDDD(p);
  return p;
}

но это тоже частный случай, да и выглядит коряво, имхо. Захочется манипулировать одновременно двумя билдерами, то опять что-то новое придумывать:

public Result enrich(Person p, Order o) {
  var iBuilder = Info.newBuilder();
  var pBuilder = p.builder();
  var oBuilder = o.builder();
  updateAAA(pBuilder, iBuilder);
  updateBBB(oBuilder, iBuilder);
  updateCCC(oBuilder, pBuilder);
  return new Result(pBuilder.build(), pBuilder.build(), iBuilder.build());
}

как тут можнро сделать красивее?

Лично мне пока самым удобным показалось то, что генерирует Avro, как тут. (генерацию setters для самих dto можно запретить, оставить только у билдеров).

S>·>Ты прав. Можно только новый тип создавать оказывается.
S>Переходите на сторону CLR. У нас всё это есть Включая "annotation processors"
Нее... мы мееедленно спускаемся.

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

S>>А что там внутри этих updateBBB()?
·>Там ещё могут быть простыни кода, ведь у нас 40 полей которые надо по всякому вычислять и проставлять. Если модификация p происходит очень сложно, то хочется это всё разрезать на мелкие кусочки по разным методам или даже классам, иногда даже реюзабельным из разных мест.
Ну, и в чём проблема? Любое поле — это всего лишь значение. Для его вычисления есть формула.
В иммутабельном мире есть одна проблема — если, к примеру, целиковое "изменение" объекта тривиально расписывается в стиле

var date = DateTime.Now;
date += TimeSpan.FromMinutes(42); // == date = date + TimeSpan.FromMinutes(42);

несмотря на его иммутабельность, сигнатуру "мутабельного" метода можно поменять

var l = new ImmutableList<int> {4, 8, 15, 16, 23};
l.Add(42);     // ah-ah! 
l = l.Add(42); // good boy!

и всё будет работать, то с отдельными свойствами композитных объектов так сделать не получится. Если у меня immutable record Point(int x, int y), то запись вроде p.x += 5 запрещена.
Нельзя и сигнатуру у сеттера поменять, чтобы он перестал быть void, а стал возвращать Point.

p1.x = p1.y = 0; // intuitievely clean, but doesn't work in immutable case
(p1.y = 0).x = 0; // in case p1.y = 0 yields Point, not int.

И вот для обхода этой проблемы предлагается конструкция with.
Она позволяет легко и очевидно перейти от мутабельного кода к иммутабельному:

var mp = new MutablePoint(0, 0);
var ip = new Point(0,0);

mp.X += 10;
ip = ip with X = 10;

if (42 mod 17 != 1)
{
   mp.X = mp.Y = 13; 
   ip = ip with { X = 13; Y = 13; }
}

S>>Почему нельзя просто сделать тот же With? Ведь при присванивании "в себя же" ескейп-анализ уберёт всю лишнюю нагрузку на GC, в итоге имеем тот же перформанс, лаконичный синтаксис, и отсутствие необходимости для каждого DTO еще и цельный билдер расписывать.
·>Как я понял, ты предлагаешь что-то вроде
·>

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

Да, а почему нет?

·>но это тоже частный случай, да и выглядит коряво, имхо. Захочется манипулировать одновременно двумя билдерами, то опять что-то новое придумывать:
·>

·>public Result enrich(Person p, Order o) {
·>  var iBuilder = Info.newBuilder();
·>  var pBuilder = p.builder();
·>  var oBuilder = o.builder();
·>  updateAAA(pBuilder, iBuilder);
·>  updateBBB(oBuilder, iBuilder);
·>  updateCCC(oBuilder, pBuilder);
·>  return new Result(pBuilder.build(), pBuilder.build(), iBuilder.build());
·>}
·>

·>как тут можнро сделать красивее?
Эмм, да всё что угодно тут будет красивее.
Хотя бы так — если уж очень хочется.

public Result enrich(Person p, Order o) {
  var i = new Info();
  (p, i) = updateAAA(p, i);
  (o, i) = updateBBB(o, i);
  (o, p) = updateCCC(o, p);
  return new Result(p, o, i);
}

·>Лично мне пока самым удобным показалось то, что генерирует Avro, как тут. (генерацию setters для самих dto можно запретить, оставить только у билдеров).
Ну, это тот самый способ со сменой сигнатуры у сеттера на возврат self. Так себе решение, по сравнению с with operator, кмк. Лучше, чем ничего, конечно.

·>Нее... мы мееедленно спускаемся.
А стадо тем временем всё дальше и дальше.

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

S>·>Там ещё могут быть простыни кода, ведь у нас 40 полей которые надо по всякому вычислять и проставлять. Если модификация p происходит очень сложно, то хочется это всё разрезать на мелкие кусочки по разным методам или даже классам, иногда даже реюзабельным из разных мест.
S>Ну, и в чём проблема? Любое поле — это всего лишь значение. Для его вычисления есть формула.
Это интересно в основном с академической точки зрения.
На практике вдруг выясняется, что некоторые поля удобнее вычислять сразу пачкой. Например, надо прописать цену, её тип, валюту и значение в долларах, притом значение цены в долларах идёт в какую-нибудь коллекцию дополнительных атрибутов в другой части документа.
Или стадиями, когда появляются частично сконструированные промежуточные объекты. Например, вначале сформировали список трейдов из заказа, потом каждому трейду прописали вознаграждение таким образом, что первый трейд берёт всё значение, а у всех остальных прописать нули. А потом нужно распределить коммиссию по этому списку трейдов пропорционально их размеру, оставляя остаток от деления последнему трейду. У объекта "трейд" все значения обязательные. Поэтому создать список трейдов для первой стадии (без коммиссии и вознаграждения) ты те сможешь, нужен список билдеров или, если иммутабельно, каких-то других, частичных типов. А если вспомнить, что список трейдов это всего лишь поле в каком-то развесистом документе, который тоже надо иммутабельно копировать...
Теоретически, конечно, это можно всё переписать функционально, на иммутабельных структурах, добавляя ещё типы, выворачивая порядок исполнения, но в итоге код получается сложнее для всяких оптимизаторов, запутаннее для человека, и далёк от спеки, который выдаёт бизнес. С билдерами же всё пишется как слышится и код хоть даже юзерам показывать можно — всё ясно что куда и откуда и в каком порядке.

S>В иммутабельном мире есть одна проблема — если, к примеру, целиковое "изменение" объекта тривиально расписывается в стиле
S>l.Add(42); // ah-ah!
Верно. Так же можно и забыть p = при updateAAA(p). Хуже того, можно ошибиться в copy-paste и получится x = updateAAA(y). С билдерами такой проблемы нет в принципе, т.к. используется одна сущность.

S>и всё будет работать, то с отдельными свойствами композитных объектов так сделать не получится. Если у меня immutable record Point(int x, int y), то запись вроде p.x += 5 запрещена.
И таких проблем с билдером нет. Поля билдера можно использовать как аккумуляторы значений из разных мест кода. Особенно хорошо, когда они коллекции.

S>И вот для обхода этой проблемы предлагается конструкция with.
S>Она позволяет легко и очевидно перейти от мутабельного кода к иммутабельному:
S>ip = ip with X = 10;
Тоже так себе, т.к. "неожиданно" меняется тип выражения: print("new position {}", mp.x += 5);

S>>>Почему нельзя просто сделать тот же With? Ведь при присванивании "в себя же" ескейп-анализ уберёт всю лишнюю нагрузку на GC, в итоге имеем тот же перформанс, лаконичный синтаксис, и отсутствие необходимости для каждого DTO еще и цельный билдер расписывать.
На ea я бы не полагался, ведь в 40 полях, разбито всё по методам-классам, коллекции, етс, это уже всё заблудится и потеряется.

S>·> p = updateDDD(p);
S>Да, а почему нет?
Помимо уже упомянутых недостатков выше, неясно зачем вообще так делать. Ну да, объект типа иммутабельный, а переменная-то внезапно мутабельная... Та же ж, вид с боку.

S>·>как тут можнро сделать красивее?
S>Эмм, да всё что угодно тут будет красивее.
S> (o, i) = updateBBB(o, i);
А теперь авто-рефакторингом добавь в updateBBB по всему коду параметр p.
Код выглядит красивее, но мейнтейнить его, внезапно, сложнее.

S>·>Лично мне пока самым удобным показалось то, что генерирует Avro, как тут. (генерацию setters для самих dto можно запретить, оставить только у билдеров).
S>Ну, это тот самый способ со сменой сигнатуры у сеттера на возврат self. Так себе решение, по сравнению с with operator, кмк. Лучше, чем ничего, конечно.
Суть в том, что есть два типа — иммутабельный dto и мутабельный билдер. И их можно конвертить между собой и явно использовать в разных частях кода.

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

vsb>В общем случае на уровне IDE не решается (к примеру из 40 методов 38 автосгенерированные, а 2 — нет и это хорошо бы видеть).
Да просто отдели их от остальных прямо в коде и напиши коммент.

vsb>И код часто смотрится не только в IDE.
Когда ты смотришь на код тебе не надо "генерировать геттеры и сеттеры"

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

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

vsb>>>>>В жаве в 2022 году нужно генерировать геттеры и сеттеры.
vsb>>>>>Это всё, что надо знать про разработчиков языка.
CC>>>>Это мелочи. Тем более что легко решается на уровне IDE

vsb>>>Это не мелочи. В общем случае на уровне IDE не решается (к примеру из 40 методов 38 автосгенерированные, а 2 — нет и это хорошо бы видеть). И код часто смотрится не только в IDE.

vaa>>в groovy не надо, она на 100% совместима с java. https://docs.groovy-lang.org/latest/html/documentation/#properties

vsb>И в Scala не надо, и в Kotlin не надо.

Еще обратил внимание на интересный факт

IronScheme 1.0.314-2d8013f github.com/IronScheme © 2007-2022 Llewellyn Pritchard (.NET Core 2.1 64-bit)
>; (define (hello x) (display x))
>; (define (f x) (hello  x))
>; (f 1)
1
>; (define (hello  x) (display (* x x)))
>; (f 3)
3

Во всех других динамически типизированных ЯП(javascript, racket, elisp, clojure)
f всегда вызывает измененную hello.
Похоже это св-во кардинально отличает jvm от dotnet(hello запеклась в f)

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

vaa>Еще обратил внимание на интересный факт

vaa>

vaa>;IronScheme 1.0.314-2d8013f github.com/IronScheme © 2007-2022 Llewellyn Pritchard (.NET Core 2.1 64-bit)
>;> (define (hello x) (display x))
>;> (define (f x) (hello  x))
>;> (f 1)
vaa>;1
>;> (define (hello  x) (display (* x x)))
>;> (f 3)
vaa>;3
vaa>;

vaa>Во всех других динамически типизированных ЯП(javascript, racket, elisp, clojure)
vaa>f всегда вызывает измененную hello.
vaa>Похоже это св-во кардинально отличает jvm от dotnet(hello запеклась в f)

А если файл запускать, а не в репле?

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

vsb>>В общем случае на уровне IDE не решается (к примеру из 40 методов 38 автосгенерированные, а 2 — нет и это хорошо бы видеть).
CC>Да просто отдели их от остальных прямо в коде и напиши коммент.

Так и делал, но это как подорожник прикладывать. Не очень спасает.

vsb>>И код часто смотрится не только в IDE.
CC>Когда ты смотришь на код тебе не надо "генерировать геттеры и сеттеры"

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

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

Тут вопрос в каком сегменте. Ява она ведь разная для андроида одна, для сервера другая.
В основном Ява для андроида. Там не догонит. Хотя Гугл продвигает Dart. Возможно и перегонит.
На серверах уже может догнать, а на десктопе давно уже перегнала.
Да и Windows для ARM потихоньку набирает обороты, то вполне и там могут произойти подвижки