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

K>·>Отдельный set-get не настолько плох. Обычно такие простые тривиальные свойства составляют небольшую долю от объёма кода и лежат в отдельных model-классах в которые редко заглядываешь. Т.е. немного упрощают и так простую проблему. Ценность невелика. Зато лишняя когнитивная нагрузка.
K>На работу с данными отдельные методы плохо ложатся.
K>Имею ввиду всякие DTO для сериализации json, или маппинга строк БД.
json обычно не просто так json, а для обмена данными с другими системами, поэтому пишется какой-нибдуь swagger,avro,etc и по нему генерится код .Код маппинга строк генерится из схемы БД.

K>Со свойствами в C# пишешь:
А ты так не пиши. Пиши хотя бы так:

[JsonProperty("is_enabled")]
public boolean IsEnabled;

и собственно всё. И ЯП тебе явно запретит всякую дичь творить в data-only маппинговых классах, логику в сеттерах.

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

K>если в set-методе всё же будет какая-то логика.
Ибо нехрен.

K>У меня вот как-то всех этих DTO/POCO/POJO достаточно ощутимая доля образуется и со свойствами в C# приятнее это всё писать, чем в Java с отдельными методами.
Если уж очень надо, то такие методы умеет IDE писать за тебя.

K>record'ы ещё завезли, но там свои нюансы хотя бы в плане поддержки разными библиотеками.
они иммутабельные. Но можно кодогенерить билдеры для них и библиотеки прожуют.

K>·>Вот эта неявная генерация — и есть магия. Если надо генерировать — так генерируй код явно.
K>Языки высокого уровня в принципе существуют из-за неявной генерации.
K>Вопрос в адекватности этой генерации и не слишком ли с ней легко выстрелить себе в ногу.
K>Те же автосвойства — это просто, понятно, никаких проблем с ними не вижу.
K>В секции set есть понятное по смыслу ключевое слово value, так же интуитивно туда ложится и field.
Тут согласен, частично. Высокий уровень это не про то как нагенерить как можно больше, а выразить как можно больше с практической точки зрения как можно меньшим набором высокоуровневых понятий. И мне кажется более адектватным проводить черту чуть раньше. Уже есть методы, которые решают задачу изменения любых полей в любом порядке и ещё много чего. Поэтому зачем вводить ещё и свойства, которые как методы, но могут менять только одно поле. А потом ещё возможность кастомизировать менять одно поле и ещё вызывать некую нотификацию.

Грубо говоря, если свести к абсурду, нам не нужна поддержка в ЯП ВУ метода "void printHelloWorld()" для которого будет сразу генериться весь нужный код, хоть это и упрощает написание кода в некоторых случаях.

K>·>Они коллапсятся. IDE неплохо умеет упрощать чтение простыней, притом неважно, поле это или просто однострочный метод. Всё выглядит одинаково.
K>Мне такие IDE не попадались.
Вот здесь смотри картинку в вопросе, обрати внимание на номера строк. Тривиальные сеттеры-гетеры задетектились и заколлапсились.