Re[3]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.12.22 17:12
Оценка: 1 (1) +4
Здравствуйте, scf, Вы писали:

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

Угу. Им бы ещё value-типы, настоящие дженерики, Expression Trees, query comprehensions, и паттерн-матчинг.
И тогда, может быть, из джавы и удастся выпилить хоть что-то приемлемое для потребления в 2022 году.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Догонит ли net java?
От: magnum2005  
Дата: 05.12.22 07:23
Оценка: 1 (1) -1 :))
Здравствуйте, vaa, Вы писали:

.Net проиграла Джаве
Догонит ли net java?
От: vaa  
Дата: 05.12.22 02:00
Оценка: -1 :))
Вот смотрю я на фичи java
очень много интересного и вкусного появилось за 15 лет с тех пор как была повешена на гвоздь.
взять теже строки в тройных кавычках, в java уже давно.
aot тоже раньше появился(правда из коробки как и нет не умеет кросскомпиляцию).
еще появился скриптинг(можно запускать исходник без компиляции).
функциональный интерфейс(можно присвоить лямбду если интерфейс состоит из единственной функции).
А ЯП?
Тут кто-то говорил про брекинг чэнжи?
Говорят что в кложуре нет ни одного до сих пор.
+ groovy(до сих пор живой!)
+ всякая экзотика типа scala, kotlin.
+ количество родных(на чистой джаве библиотек) все еще кратно больше чем в дотнете. и разница вроде небольшая. всего пару лет.

ЗЫ по нативно компилируемым ЯП ощущение что еще долго будет доминировать c++.
взять тот же оберон, библиотек ноль(для БД в зачаточном состоянии например). Хотя компилятор мощный.
или раст, взял quick_xml промучался с владением полдня.
в итоге тэги типа <a /> не видит в упор. а мне он именно и нужен.

PPS Или кол-во IDE? Eclipse Idea Netbeans

внезапно с удивлением обнаружил на пк OpenJDK Runtime Environment Microsoft-25199 (build 11.0.12+7)
Точно не ставил!


rundll32 user32.dll,func arg кстати прямо указывает на корни dotnet core (для сравнения: dotnet app.dll arg)
☭ ✊ В мире нет ничего, кроме движущейся материи.
Отредактировано 05.12.2022 4:13 Разраб . Предыдущая версия . Еще …
Отредактировано 05.12.2022 3:49 Разраб . Предыдущая версия .
Отредактировано 05.12.2022 2:50 Разраб . Предыдущая версия .
Re[2]: Догонит ли net java?
От: Константин Б. Россия  
Дата: 05.12.22 06:51
Оценка: +2 :)
Здравствуйте, scf, Вы писали:

scf>Сумбурно и мысль не очень понятна, но вот моё мнение: дотнет как язык С# и платформа лучше джавы, но никогда не догонит её по популярности, т.к. доверять бесплатным решениям Майкрософт дураков нет, и к платным тоже хватает вопросов.


Т.е. доверять бесплатным решениям Оракла или Гугла — дураки есть?
Re[18]: Догонит ли net java?
От: · Великобритания  
Дата: 06.12.22 17:14
Оценка: 5 (2)
Здравствуйте, Sinclair, Вы писали:

S>·>А что такое придумать, чтобы прям из коробки в ЯП было и было юзабельно и достаточно универсально — не очень ясно.

S>Ну, в дотнете это работает из коробки через Source Generators.
Ох, ты прав. Меня vsb смутил. Можно же аннотацию на рекорды вешать.

S>Вон, пару лет назад кто-то уже с этим игрался: https://justsimplycode.com/2020/12/06/auto-generate-builders-using-source-generator-in-net-5/

S>Наверняка к данному моменту уже есть более-менее отлаженная реализация.
Ага, в java это уже 3 года доступно, а я торможу. Попробую сейчас...

S>Преимущество в том, что это никакие не хаки, а официально поддерживаемая технология. Интегрирована с интеллисенсом и билд-процессом.

S>Аннотировал нужный Record-класс атрибутом — и поехали.
Угу, в java то же, притом раньше, чем SG придумали.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 06.12.2022 17:32 · . Предыдущая версия .
Re[10]: Догонит ли net java?
От: · Великобритания  
Дата: 06.12.22 17:21
Оценка: 4 (2)
Здравствуйте, vsb, Вы писали:

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

Вот тут интересное решение, позволяет навешивать генерацию даже на чужие типы. https://github.com/randgalt/record-builder
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.12.22 09:04
Оценка: 1 (1) +1
Здравствуйте, vaa, Вы писали:

Тут вопрос в каком сегменте. Ява она ведь разная для андроида одна, для сервера другая.
В основном Ява для андроида. Там не догонит. Хотя Гугл продвигает Dart. Возможно и перегонит.
На серверах уже может догнать, а на десктопе давно уже перегнала.
Да и Windows для ARM потихоньку набирает обороты, то вполне и там могут произойти подвижки
и солнце б утром не вставало, когда бы не было меня
Re[2]: Догонит ли net java?
От: CreatorCray  
Дата: 05.12.22 11:14
Оценка: -2
Здравствуйте, vsb, Вы писали:

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

vsb>Это всё, что надо знать про разработчиков языка.
Это мелочи. Тем более что легко решается на уровне IDE
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Догонит ли net java?
От: iHateBrightVictories Россия  
Дата: 11.12.22 04:11
Оценка: +1 -1
Здравствуйте, vsb, Вы писали:

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


https://projectlombok.org/features/GetterSetter
Re[20]: Догонит ли net java?
От: · Великобритания  
Дата: 11.12.22 18:29
Оценка: +1 -1
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.

НС>·>Т.е. code-first, далеко не всегда работает
НС>А я и не говорил что работает всегда. Зато когда оно работает ...
Хреново оно работает.

НС>·>А вот
Автор: varenikAA
Дата: 07.09.20
и результат такого подхода.

НС>Нет, это результат кривого генератора.
Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически.
Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных.
Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание. Но зачем придумывать ещё один язык?..

НС>>>>>Но генератор тогда приносит минимум пользы, основное API приходится описывать руками.

НС>>>·>Не API, а сценарии.
НС>>>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
НС>·>Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.
НС>Ничего не понял. API основанное на сценариях — частный случай?
Смотри мою эту цитату и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.".

НС>>>Непонятен вопрос.

НС>·>Ну вот нужен тебе сервис для общения через protobuf. Что ты предлагаешь писать вручную?
НС>Я не понимаю какое это имеет отношение к разговору.
Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю.
Как правило по модели данных, описанных в виде .proto используют protoc генератор кода, создающий классы на разных яп. Ты, как я понял, предлагаешь вначале напедалить код (как именно — не сообщаешь) и попытаться из него сгенерить .proto-описания.

НС>>>·> Тебе по сути надо преобразовывать языковые конструкции в пачки байтов, в виде json/fix/protobuf/etc. Как именно это будет происходить?

НС>>>Какое это имеет отношение к обсуждаемому вопросу?
НС>·>Ты заявил, что ты собрался писать что-то вручную. Объясни как ты будешь писать тот же json вручную
НС>Я не заявлял что я собираюсь писать json вручную. Я говорил о классах модели.
Что за классы модели? И причём тут генерация кода?

НС>·>1. описание ddl для rdbms -> генерим код для бэка на java/c#

НС>Разные модели — раз.
НС>Разные модели — два.
Где что разное? Модели чего?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Догонит ли net java?
От: Gt_  
Дата: 05.12.22 14:10
Оценка: 3 (1)
Gt_>>дураков нету. потому они и заставили оракл отдать права консорциуму и выложить исходники в опен соурс

B>Что только лишний раз доказывает, что опенсорс — тупое, бесполезное стадо. Неужели ИМЕЯ СОРСЫ они не могли "всем миром" обогнать каких-то индусов из MS?? Языки-то отличаются как небо и земля! Библиотеки — аналогично. Я когда писал элементарный сетевой обмен, о___ел насколько много ШЛАКА потребовалось для тривиальной задачи.


нет, это лишний раз показывает что есть достаточно большой процент индюшатины, встречавшийся лишь с тривиальными задачами, которые они и не могли решить. но слава яйцам индустрию не интересуют индюшачьи сложности, они ориентируется на профессионалов. потому мы и получали созданные "всем миром" опенсоурсные кафки, хадупы, касандры и прочие серьезные тулы, что нет и уже не будет в мире .net
Отредактировано 05.12.2022 15:19 Gt_ . Предыдущая версия . Еще …
Отредактировано 05.12.2022 14:11 Gt_ . Предыдущая версия .
Re[18]: Догонит ли net java?
От: · Великобритания  
Дата: 11.12.22 12:49
Оценка: 3 (1)
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Я говорю о language-agnostic спеке. Когда ты пишешь какой-нибудь rest api, то у тебя уже должна быть какая-то спека, которую ты выдаёшь консьюмерам api.

НС>У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.
А вот
Автор: varenikAA
Дата: 07.09.20
и результат такого подхода. Спека становится неюзабельна.

Moedelo.DocumentsRegister.Api.Models.Dto.ApiDataResponseDto`1[[System.Collections.Generic.List`1[[Moedelo.DocumentsRegister.Api.Models.Dto.DocumentRegisterDto, Moedelo.DocumentsRegister.Api, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]

но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Догонит ли net java?
От: Baiker  
Дата: 05.12.22 05:49
Оценка: 2 (1)
Здравствуйте, vaa, Вы писали:

vaa>Вот смотрю я на...


А ты не смотри "на"... ты ДУМАЙ, на... тогда может сможешь формулировать чётко свои мысли, на...
Re[6]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 18:13
Оценка: 2 (1)
Здравствуйте, Sinclair, Вы писали:

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


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

Завезли пару месяцев назад. Да и то — большинство боится использовать последнюю версию и предпочитают сидеть на LTS, следующий будет через год примерно. Я даже скажу, что большинство боится использовать последний LTS и предпочитает сидеть на предыдущем LTS Поэтому он вроде как есть, но скорей в будущем.
Re[11]: Догонит ли net java?
От: vsb Казахстан  
Дата: 06.12.22 14:20
Оценка: 1 (1)
Здравствуйте, vaa, Вы писали:

vaa>set! не понимает такой синтаксис


Ну значит это не scheme, а просто похожий на него язык. set! в scheme это фундаментальная конструкция.
Re: Догонит ли net java?
От: scf  
Дата: 05.12.22 05:59
Оценка: -1
Здравствуйте, vaa, Вы писали:

vaa>Вот смотрю я на фичи java


Сумбурно и мысль не очень понятна, но вот моё мнение: дотнет как язык С# и платформа лучше джавы, но никогда не догонит её по популярности, т.к. доверять бесплатным решениям Майкрософт дураков нет, и к платным тоже хватает вопросов.
Re: Догонит ли net java?
От: CreatorCray  
Дата: 05.12.22 07:48
Оценка: +1
Здравствуйте, vaa, Вы писали:

vaa>rundll32 user32.dll,func arg кстати прямо указывает на корни dotnet core (для сравнения: dotnet app.dll arg)

Чот я не распарсил кто у тебя на ком стоял, но если чо — rundll32 заметно больше годочков чем дотнету в целом
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 09:18
Оценка: +1
В жаве в 2022 году нужно генерировать геттеры и сеттеры.

Это всё, что надо знать про разработчиков языка.
Re[6]: Догонит ли net java?
От: · Великобритания  
Дата: 05.12.22 14:19
Оценка: :)
Здравствуйте, vsb, Вы писали:

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

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

vsb>Глаза закрывать? У меня есть файл, описывающий АПИ. В нём 5 строк кода, вызывающего что-то. В запросе/ответе по 30 полей, к примеру. Итого 65 строк осмысленного кода. И к этим 65 строкам прилагается 480 строк геттеров-сеттеров. И таких запросов, скажем, 20 штук. Лёгким движением руки из 1200 строк получаем 10 000.

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

vsb>·>Во-вторых, если поле приватное и никак не используется, то будет warning в idea.

vsb>Не понял, при чём тут приватное поле.
Ну обычно объявляется приватное поле и публичные геттер-сеттер для него.

vsb>·>Ну и вообще, есть record и даже всякие любительские штуки типа lombok.

vsb>record пока не готов, хотя я тоже жду, пока они добавят withers. Для Hibernate он вряд ли когда-нибудь будет готов, поэтому полностью он проблему не решит, но ничего другого от разработчиков языка мы видимо не дождёмся.
Не, record вполне готов. Туда пихать ничего лучше не надо. Если что-то добавлять для билдеров, то это пусть лучше будет какая-то другая фича.

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

vsb>lombok это да, это единственное, что хоть как-то спасает. Но надо понимать, что lombok это ещё один язык, похожий на Java. Я бы предпочёл писать на Java, а не на lombok.

Согласен. Впрочем создать dto+builder+withers+toString можно при отсутствии альтернатив.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Догонит ли net java?
От: scf  
Дата: 05.12.22 17:26
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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


value-типы — перфоманс-вкусовщина, ненастоящие дженерики всех устраивают, про expression trees и query comprehensions я и не слышал, а паттерн-матчинг завезли. Не скаловский, конечно, но ADT можно рисовать.
Re[13]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 09.12.22 13:12
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Да всякое бывает. По ddl можно генерить код на ЯП, чтобы строить те же sql запросы с type-safety, без всякого ОО.


Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака.

·>Ты, видимо, об ORM говоришь, неясно причём тут оно.


Давай я тебе на простом примере продемонстрирую. Возьмем REST API и метод получения списка сущностей. Для одного типа сущностей мы, как правило, имеем один uri (часто это явно зафиксировано в гайдлайнах), и, как следствие, один метод контроллера сервиса. Если при этом мы имеем несколько разных юзкейсов, то сумма этих юзкейсов порождает набор фильтров в параметрах на все случаи жизни.
Далее из этого автоматически генерируется OpenAPI spec (тут все еще ОК, потому что это все еще модель REST), а потом по ней клиент. И вот тут нам генератор породит и на клиенте метод-всемогутор, который, конечно, обладает максимальной гибкостью, но при этом еще и максимально неудобен, потому что нет ни одного юзкейса где нужны были бы все фильтры. И во вручную написанном клиенте вместо одного метода-всемогутера было бы N методов под каждый юзкейс.
Аналогичная ситуация и с классами-DTO.
Теоретически можно было бы обвесить метод контроллера метой, которая бы описывала юзкейсы, и которая передавалась бы в составе OpenAPI spec, а генератор эту мету доставал бы и генерил удобного клиента, но на практике я такого генератора не видел даже близко.
Аналогичная ситуация и с ORM. Вся идея с тем, что мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API работает только на демках. Еще хуже работает когда эти POCO не вручную пишутся, а генерируются из схемы БД. Поэтому в реальности в лучшем случае только сабсет модели общий для всей цепочки, а полная модель у ORM, REST и клиента у каждого своя.
Это я еще не вспоминаю про те же ad-hoc типы в ORM, которых в Java нет, но там где они есть это очень мощная штука.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 09.12.22 13:16
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Ну издалека оно так кажется. Когда в жаве, голанге и других языках годами вообще ничего существенного не добавляется, а в .NET каждый релиз куча новых фич.


Да не особо то и куча. Мелочевка в основном. Но в целом это не вопрос тянуть все блестящее (если ты внимательно посмотришь — все новые фичи это не просто затянутое откуда то, а основательно преломленное через реалии и идеологию шарпа), а вопрос подхода и инвестиций.
Вот где сорочий подход, так это в Скале.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[17]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.12.22 21:46
Оценка: +1
Здравствуйте, ·, Вы писали:
S>>·>Немного многословно, приходится типы полей прописывать, но вполне юзабельно.
S>> Кстати в Java завезли аналог IEnumerable c yield
·>yield как конструкцию языка нет, не завезли. Другие средства есть на уровне библиотек, вроде хватает.

S>>То есть вызов осуществляется с права на лево как в C#?

·>Классика map-reduce — вначале строится цепочка преобразований (flatmaps & Co) потом коллектор (reduce). Коллектор тащит всё через цепочку. Вроде слева направо. Не знаю что ты имеешь в виду "как в C#".
Ну в C# ты получаешь IEnumerable. Причем не первый а последний. При MoveNext последний дергает MoveNext предыдущего.
И получается, что у самого первого будет проходов равного его размера.
То есть IEnumerable.Range(1,3).Select(i=> new {twice = i * 2, str = "val" + i}).Where(v => v.twice > 3 && v.str.contains("3"));

можно разложить на несколко операторов
list=IEnumerable.Range(1,3);
Обозначим анонимный тип new {twice = i * 2, str = "val" + i} как TResult
select=Enumerable.Select<int,TResult>(list, i=> new {twice = i * 2, str = "val" + i})
и поледний
result=IEnumerable.Where<TResult>(select, v => v.twice > 3 && v.str.contains("3"));

В Итоге ты получаешь IEnumerable<TResult>

И когда ты начинаешь обход или то вызываешь MoveNext у result

result вызовет MoveNext у select, а select у list.
То есть вызов идет с права на лево
Можно посмотреть на исходники https://github.com/microsoft/referencesource/blob/master/System.Core/System/Linq/Enumerable.cs
Ленивость сделана через yield.
Вернее yield создает анонимный класс реализующий IEnumerable Что такое yield и как он работает в C#?

Внутри этого класса State Machine. Кстати по этому же принципу работает и async/await/
То есть компилятор берет на себя генерацию анонимных классов (или уже существующих как WhereEnumerableIterator<TSource>) реализующих State Machine и методов IEnumerable MoveNext и Current в итоге.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 10.12.2022 8:30 Serginio1 . Предыдущая версия . Еще …
Отредактировано 10.12.2022 8:22 Serginio1 . Предыдущая версия .
Отредактировано 09.12.2022 21:48 Serginio1 . Предыдущая версия .
Re[4]: Догонит ли net java?
От: VladiCh  
Дата: 11.12.22 09:18
Оценка: +1
Здравствуйте, vsb, Вы писали:

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


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


HBV>>https://projectlombok.org/features/GetterSetter


vsb>Я про жаву а не про ломбок.


Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.
Re[5]: Догонит ли net java?
От: · Великобритания  
Дата: 11.12.22 12:41
Оценка: -1
Здравствуйте, VladiCh, Вы писали:

vsb>>Я про жаву а не про ломбок.

VC>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.
Неправда.

Lombok is a huge hack that will only compile using javac or eclipse's compiler.

Мы это уже тут обсудили выше и в качестве действительно стандартного решения я нашел https://github.com/Randgalt/record-builder
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Догонит ли net java?
От: vsb Казахстан  
Дата: 11.12.22 18:22
Оценка: +1
Здравствуйте, VladiCh, Вы писали:

HBV>>>https://projectlombok.org/features/GetterSetter


vsb>>Я про жаву а не про ломбок.


VC>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.


Ломбок это отдельный язык. Похожий на Java, но это не Java. У Java-компилятора нет никаких плагинов. То, что он реализован, как annotation processing tool и в процессе вызова использует внутренние API компилятора через reflection и прочее — не делает его просто плагином. В Java нет разрешённого способа реализовать функционал ломбока без хаков. Lombok ломается при каждой крупной переработке внутренностей компилятора. И когда-нибудь сломается окончательно.

PS при этом в своих проектах я его использую. Потому, что это прагматичный подход. Хак, не хак, а он пока работает и в IDE поддерживается неплохо. А когда перестанет работать — сделаю delombok. Тем не менее нормальной такую ситуацию я не считаю.
Отредактировано 11.12.2022 18:25 vsb . Предыдущая версия . Еще …
Отредактировано 11.12.2022 18:24 vsb . Предыдущая версия .
Re[6]: Догонит ли net java?
От: VladiCh  
Дата: 11.12.22 23:51
Оценка: +1
Здравствуйте, ·, Вы писали:

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


vsb>>>Я про жаву а не про ломбок.

VC>>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.
·>Неправда.
·>

Lombok is a huge hack that will only compile using javac or eclipse's compiler.

·>Мы это уже тут обсудили выше и в качестве действительно стандартного решения я нашел https://github.com/Randgalt/record-builder

Не понял, что в том что я сказал неправда? Используется стандартный механизм "JSR 269 Pluggable Annotation Processing API"
То что во внутренней логике у него хак на хаке — это здесь вторичное. Большинство стандартных билд механизмов поддерживается — https://projectlombok.org/contributing/lombok-execution-path
Re[22]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 12.12.22 16:35
Оценка: +1
Здравствуйте, Pauel, Вы писали:

P>Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов. Во вторых, меньше интеграционного кода, меньше шансов сломать. В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.


В-четвертых средства обобщения полноценного мейнстримового языка на две головы выше любого "стандартного" местечкового языка. В-пятых инструментарий мейнстримового языка где то в стратосфере относительно инструментария для какого нибудь нишевого решения типа OpenAPI.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[24]: Догонит ли net java?
От: · Великобритания  
Дата: 12.12.22 16:48
Оценка: +1
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Всегда хреново работает?

НС>·>Угу.
НС>Сильное заявление. Обоснования будут?
Вот же
Автор: varenikAA
Дата: 07.09.20
, выше уже приводил. Не можете даже шарп из шарпа заюзать, в итоге "писать клиентов нужно руками".

НС>>>Ну вот, ты сам на все ответил.

НС>·>Ага. Ведь гланды можно удалять через разные места.
НС>Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает.
Нет никакого богом данного языка описания модели, пока ты сам его не придумаешь. Ты ещё так и не ответил на вопросы: "как формализовать-то? как валидировать?".

НС>>>Это наоборот, заставлять писать руками на OpenAPI это придумывать еще один язык.

НС>·>OpenAPI это уже существующий и стандартизованный язык.
НС>Тем не менее это еще один язык.
В моей схеме это второй и последний язык, который в твоей схеме тоже есть. Только ты пытаешься генерить на этом языке из твоих аннотаций, которые по сути edsl, т.е. третий язык.

НС>>>Я ее уже смотрел. Это не отвечает на мои вопросы.

НС>·>Ок. Отвечаю на этот вопрос: "API основанное на сценариях — частный случай?"
НС>·>Понятия не имею откуда ты это взял
НС>

НС>>>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
НС>·> Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.
НС>> Ничего не понял. API основанное на сценариях — частный случай?

Ну т.е. это ты сам придумал, т.к. ничего не понял. Про частный случай я сказал только вот тут про твой API с одинм методом-всемогутером:

НС>И вот тут нам генератор породит и на клиенте метод-всемогутор, который, конечно, обладает максимальной гибкостью, но при этом еще и максимально неудобен, потому что нет ни одного юзкейса где нужны были бы все фильтры.
Это довольно частный пример.


НС>>>·> и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.".

НС>>>Ну и? Какой тут бенефит от генератора?
НС>·>В том, что писать будешь используя сгенерированный код
НС>В чем бенефит?
Ниже написал, после запятой.

НС>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.

НС>Что нужно писать с нуля и почему?
Вот по твоему же заявлению: "писать клиентов нужно руками".

НС>Почему не хватает средств реюза языка и нужен генератор?

Пусть дали тебе .proto-файл. Что делать будешь? Что реюзать?

НС>>>·>Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю.

НС>>>Я говорю о генерации моделей, я с самого начала про это написал. Генерировать сериализаторы, по крайней мере в дотнете, не нужно. Они сами справляются.
НС>·>Что такое генерация моделей?
НС>Генерация классов C#/Java по какому то внешнему описанию не на C#/Java.
Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?

НС>·> И с какой целью их генерировать?

НС>Для описания метаданных в терминах компилятора строго типизированных язков.
Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?

НС>·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации.

НС>Нет конечно.
Почему? Есть спеки, которые описывают как конкретные сообщения преобразуются в конкретные байты и обратно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 12.12.2022 17:43 · . Предыдущая версия .
Re[16]: Догонит ли net java?
От: Gt_  
Дата: 12.12.22 17:10
Оценка: +1
НС>>>Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака.
НС>·>Whatever, другое api может иметь другое описание и по нему тоже генериться код.

НС>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.


а как предлагается написать модель, если требуется два вида табличек — основная и историческая ? историческую наследовать от основной ? а как там у орм потом с планами не поедет крыша от наследований ? и зачем на это тратить ресурсы, если внешняя приблуда может сгенерить модели без всякого наследования ?
Re[37]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.12.22 15:26
Оценка: +1
Здравствуйте, ·, Вы писали:

S>>Есть Source Generator. Можно, что угодно нагенерить!

·>Новости из будущего? Вот когда нагенерите, тогда приходите, может сабж и случится.
·>Впрочем, вижу вот целых 2 месяца назад наконец-то появилась какая-то поделка https://github.com/s-tarasov/ST.NSwag.ServerSourceGenerator
По уму там и Source Generator не нужен. Он нужен только для модель изменяемая.
А так я не вижу проблем. Можно и самому по модели методы написать и DTO сгенерить. Не вижу каких то проблем.

Только странно как то из описания генерить сервер. Больше нужен клиент.
и солнце б утром не вставало, когда бы не было меня
Re[3]: Догонит ли net java?
От: Слава  
Дата: 05.12.22 09:16
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>Т.е. доверять бесплатным решениям Оракла или Гугла — дураки есть?


Да. С избытком этих дураков.
Re[3]: Догонит ли net java?
От: Gt_  
Дата: 05.12.22 09:34
Оценка:
scf>>Сумбурно и мысль не очень понятна, но вот моё мнение: дотнет как язык С# и платформа лучше джавы, но никогда не догонит её по популярности, т.к. доверять бесплатным решениям Майкрософт дураков нет, и к платным тоже хватает вопросов.

КБ>Т.е. доверять бесплатным решениям Оракла или Гугла — дураки есть?


дураков нету. потому они и заставили оракл отдать права консорциуму и выложить исходники в опен соурс, что бы свести риски от придури оакла к абсолютному нулю.
Re[3]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 11:20
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

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

Это не мелочи. В общем случае на уровне IDE не решается (к примеру из 40 методов 38 автосгенерированные, а 2 — нет и это хорошо бы видеть). И код часто смотрится не только в IDE.
Re[4]: Догонит ли net java?
От: vaa  
Дата: 05.12.22 11:58
Оценка:
Здравствуйте, vsb, Вы писали:

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


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

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

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


в groovy не надо, она на 100% совместима с java. https://docs.groovy-lang.org/latest/html/documentation/#properties
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[4]: Догонит ли net java?
От: · Великобритания  
Дата: 05.12.22 12:25
Оценка:
Здравствуйте, vsb, Вы писали:

CC>>Это мелочи. Тем более что легко решается на уровне IDE

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

Скорее проблема в том, что новое добавленное поле можно забыть прописать в hashcode или equals, но ведь его и не всегда нужно и прописывать... неясно как такое решить, кроме как тестами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Догонит ли net java?
От: Baiker  
Дата: 05.12.22 12:25
Оценка:
Здравствуйте, vsb, Вы писали:

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


vsb>Это всё, что надо знать про разработчиков языка.


Ты имеешь ввиду, что там нет приятного сахарка типа

int Age {get;set;}


?
Re[4]: Догонит ли net java?
От: Baiker  
Дата: 05.12.22 12:32
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>дураков нету. потому они и заставили оракл отдать права консорциуму и выложить исходники в опен соурс


Что только лишний раз доказывает, что опенсорс — тупое, бесполезное стадо. Неужели ИМЕЯ СОРСЫ они не могли "всем миром" обогнать каких-то индусов из MS?? Языки-то отличаются как небо и земля! Библиотеки — аналогично. Я когда писал элементарный сетевой обмен, о___ел насколько много ШЛАКА потребовалось для тривиальной задачи.
Re[5]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 12:53
Оценка:
Здравствуйте, 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


И в Scala не надо, и в Kotlin не надо.
Re[5]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 12:58
Оценка:
Здравствуйте, ·, Вы писали:

CC>>>Это мелочи. Тем более что легко решается на уровне IDE

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

Что значит "зачем их видеть"? Глаза закрывать? У меня есть файл, описывающий АПИ. В нём 5 строк кода, вызывающего что-то. В запросе/ответе по 30 полей, к примеру. Итого 65 строк осмысленного кода. И к этим 65 строкам прилагается 480 строк геттеров-сеттеров. И таких запросов, скажем, 20 штук. Лёгким движением руки из 1200 строк получаем 10 000.

·>Во-вторых, если поле приватное и никак не используется, то будет warning в idea.


Не понял, при чём тут приватное поле.

·>Ну и вообще, есть record и даже всякие любительские штуки типа lombok.


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

lombok это да, это единственное, что хоть как-то спасает. Но надо понимать, что lombok это ещё один язык, похожий на Java. Я бы предпочёл писать на Java, а не на lombok.

·>Скорее проблема в том, что новое добавленное поле можно забыть прописать в hashcode или equals, но ведь его и не всегда нужно и прописывать... неясно как такое решить, кроме как тестами.


Такой проблемы у меня нет, я не использую эти поля в hashcode/equals и вообще не понимаю, кому это может быть надо.
Отредактировано 05.12.2022 12:59 vsb . Предыдущая версия .
Re[3]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 12:58
Оценка:
Здравствуйте, Baiker, Вы писали:

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


vsb>>Это всё, что надо знать про разработчиков языка.


B>Ты имеешь ввиду, что там нет приятного сахарка типа


B>
B>int Age {get;set;}
B>


B>?


да.
Re[7]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 14:37
Оценка:
Здравствуйте, ·, Вы писали:

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 будет вполне приятно. Но пока — не очень.
Отредактировано 05.12.2022 14:42 vsb . Предыдущая версия . Еще …
Отредактировано 05.12.2022 14:41 vsb . Предыдущая версия .
Отредактировано 05.12.2022 14:40 vsb . Предыдущая версия .
Отредактировано 05.12.2022 14:38 vsb . Предыдущая версия .
Re[8]: Догонит ли net java?
От: · Великобритания  
Дата: 05.12.22 15:10
Оценка:
Здравствуйте, 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 как в том анекдоте про двух быков: "мы медленно-медленно спустимся с горы...".
Проект медленно пишется и годами поддерживается большими командами.
А если надо быстро-быстро бежать, то есть всякие груви котлины и скалы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Догонит ли net java?
От: scf  
Дата: 05.12.22 16:24
Оценка:
Здравствуйте, vsb, Вы писали:

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


В 2022 уже не надо, см. https://docs.oracle.com/en/java/javase/14/language/records.html
Re[3]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 16:55
Оценка:
Здравствуйте, scf, Вы писали:

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


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


Я в курсе. Это пока не юзабельно.
Re[9]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 17:05
Оценка:
Здравствуйте, ·, Вы писали:

·>По-моему 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 делает — так нельзя делать.
Отредактировано 05.12.2022 17:06 vsb . Предыдущая версия . Еще …
Отредактировано 05.12.2022 17:05 vsb . Предыдущая версия .
Re[10]: Догонит ли net java?
От: · Великобритания  
Дата: 05.12.22 17:39
Оценка:
Здравствуйте, 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 { ... } и ты его экземпляр уже как-то получишь.
Ты прав. Можно только новый тип создавать оказывается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.12.22 17:51
Оценка:
Здравствуйте, 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}";
...

? Круто, молодцы парни, быстро идут вперед. Ещё недавно нельзя было.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Догонит ли net java?
От: vsb Казахстан  
Дата: 05.12.22 18:09
Оценка:
Здравствуйте, ·, Вы писали:
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 и тд.

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


Я вообще не понимаю этого ограничения. Иммутабельность это хорошо, кто бы спорил. Но всему своё место. А уж в жаве, в которой испокон веков фреймворки писались для мутабельных бинов, впихивать это насильно — ну такое. Пускай и иммутабельность будет и мутабельность.
Отредактировано 05.12.2022 18:16 vsb . Предыдущая версия .
Re[11]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.12.22 18:10
Оценка:
Здравствуйте, ·, Вы писали:
·>По-моему фигня какая-то, первое — просто сахарок, который 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"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Догонит ли net java?
От: · Великобритания  
Дата: 05.12.22 18:39
Оценка:
Здравствуйте, 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"
Нее... мы мееедленно спускаемся.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[13]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.12.22 18:53
Оценка:
Здравствуйте, ·, Вы писали:

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, кмк. Лучше, чем ничего, конечно.

·>Нее... мы мееедленно спускаемся.

А стадо тем временем всё дальше и дальше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отредактировано 05.12.2022 19:01 Sinclair . Предыдущая версия .
Re[14]: Догонит ли net java?
От: · Великобритания  
Дата: 05.12.22 22:26
Оценка:
Здравствуйте, 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 и мутабельный билдер. И их можно конвертить между собой и явно использовать в разных частях кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 05.12.2022 22:27 · . Предыдущая версия .
Re[4]: Догонит ли net java?
От: CreatorCray  
Дата: 06.12.22 00:08
Оценка:
Здравствуйте, vsb, Вы писали:

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

Да просто отдели их от остальных прямо в коде и напиши коммент.

vsb>И код часто смотрится не только в IDE.

Когда ты смотришь на код тебе не надо "генерировать геттеры и сеттеры"
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: Догонит ли net java?
От: vaa  
Дата: 06.12.22 03:22
Оценка:
Здравствуйте, 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)
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[7]: Догонит ли net java?
От: vsb Казахстан  
Дата: 06.12.22 08:52
Оценка:
Здравствуйте, 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)

А если файл запускать, а не в репле?
Re[5]: Догонит ли net java?
От: vsb Казахстан  
Дата: 06.12.22 08:54
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

CC>Да просто отдели их от остальных прямо в коде и напиши коммент.

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

vsb>>И код часто смотрится не только в IDE.

CC>Когда ты смотришь на код тебе не надо "генерировать геттеры и сеттеры"

Когда я смотрю на код, мне хочется видеть код, а не автосгенерированную лабуду. Если ты гитхаб научишь сворачивать блоки, обозначенные комментариями автоматом, я может и соглашусь, что это приемлемо. Пока не научил — не соглашусь. Даже идея их не сворачивает сама, приходится щёлкать по каждому блоку.
Re[8]: Догонит ли net java?
От: vaa  
Дата: 06.12.22 09:23
Оценка:
Здравствуйте, vsb, Вы писали:

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


"multiple definitions of identifier"
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[9]: Догонит ли net java?
От: vsb Казахстан  
Дата: 06.12.22 09:37
Оценка:
Здравствуйте, vaa, Вы писали:

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


vaa>"multiple definitions of identifier"


Видимо какие-то особенности репла.

А если в файле написать:

(set! (hello (x) (display x)))
(define (f x) (hello  x))
(f 1)
(set! (hello (x) (display (* x x))))
(f 3)
Re[10]: Догонит ли net java?
От: vaa  
Дата: 06.12.22 12:33
Оценка:
Здравствуйте, vsb, Вы писали:

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


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


vaa>>"multiple definitions of identifier"


vsb>Видимо какие-то особенности репла.


vsb>А если в файле написать:


vsb>
vsb>(set! (hello (x) (display x)))
vsb>(define (f x) (hello  x))
vsb>(f 1)
vsb>(set! (hello (x) (display (* x x))))
vsb>(f 3)
vsb>


set! не понимает такой синтаксис
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[15]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.12.22 13:50
Оценка:
Здравствуйте, ·, Вы писали:

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


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

·>Верно. Так же можно и забыть 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>>Да, а почему нет?
·>Помимо уже упомянутых недостатков выше, неясно зачем вообще так делать. Ну да, объект типа иммутабельный, а переменная-то внезапно мутабельная... Та же ж, вид с боку.
Начинаю склоняться к тому, что такой подход плохо подходит для "толстых" объектов.
Для маленьких и несложных он подходит гораздо лучше — ну вот та же дата, или какой-нибудь Decimal. Для них иммутабельность абсолютно органична, т.к. если уж мы что меняем, так оно меняет объект "полностью".
Для ваших толстых DTO алгебра несколько другая; тут, действительно, с принудительно-иммутабельными структурами проще напороть, чем без них.

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

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

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

S>>Ну, это тот самый способ со сменой сигнатуры у сеттера на возврат self. Так себе решение, по сравнению с with operator, кмк. Лучше, чем ничего, конечно.
·>Суть в том, что есть два типа — иммутабельный dto и мутабельный билдер. И их можно конвертить между собой и явно использовать в разных частях кода.
Вообще да, в целом выглядит всё же получше, чем цепочка иммутабельных преобразований. Единственное что меня царапает — так это бойлерплейт в билдере. Если автоматизировать порождение билдеров на основе рекорд-класса — то, пожалуй, такой подход будет лучше всего остального.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Догонит ли net java?
От: · Великобритания  
Дата: 06.12.22 14:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>Начинаю склоняться к тому, что такой подход плохо подходит для "толстых" объектов.
S>Для маленьких и несложных он подходит гораздо лучше — ну вот та же дата, или какой-нибудь Decimal. Для них иммутабельность абсолютно органична, т.к. если уж мы что меняем, так оно меняет объект "полностью".
S>Для ваших толстых DTO алгебра несколько другая; тут, действительно, с принудительно-иммутабельными структурами проще напороть, чем без них.
Вот именно. А у "тонких" объектов и проблемы с конструктором нет, ибо там два-три параметра и вся эта шелуха с withers особо-то и не нужна.

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

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

S>Заодно поправим и возвращаемые параметры.

Впрочем, в java нет туплов, а если бы были может IDEA могла бы и возвращаемые значения с Use Any Var рефакторить, хз. Но в любом случае, это уже был бы более сложный двойной рефакторинг — и параметр, и возвращаемое значение одновременно и всё неясно ради чего. Создали лишнюю сложность с иммутабельностью и приходится теперь героически бороться туплами и хитрыми рефакторингами.

S>·>Суть в том, что есть два типа — иммутабельный dto и мутабельный билдер. И их можно конвертить между собой и явно использовать в разных частях кода.

S>Вообще да, в целом выглядит всё же получше, чем цепочка иммутабельных преобразований. Единственное что меня царапает — так это бойлерплейт в билдере. Если автоматизировать порождение билдеров на основе рекорд-класса — то, пожалуй, такой подход будет лучше всего остального.
Вот об этом и разговор. Пока, как мне кажется, более вменяемый подход это генерация кода на основе какого-нибудь описания протокола типа avro. Потом есть lombok с @Builder-аннотацией и т.п., но работает оно через хаки. Ещё в той же IDEA есть кнопочка "сгенерить билдер", которая всё сделает, но это один раз, после этого — добавление нового поля требует бОльших усилий.
А что такое придумать, чтобы прям из коробки в ЯП было и было юзабельно и достаточно универсально — не очень ясно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.12.22 16:07
Оценка:
S>>·>Суть в том, что есть два типа — иммутабельный dto и мутабельный билдер. И их можно конвертить между собой и явно использовать в разных частях кода.
S>>Вообще да, в целом выглядит всё же получше, чем цепочка иммутабельных преобразований. Единственное что меня царапает — так это бойлерплейт в билдере. Если автоматизировать порождение билдеров на основе рекорд-класса — то, пожалуй, такой подход будет лучше всего остального.
·>Вот об этом и разговор. Пока, как мне кажется, более вменяемый подход это генерация кода на основе какого-нибудь описания протокола типа avro. Потом есть lombok с @Builder-аннотацией и т.п., но работает оно через хаки. Ещё в той же IDEA есть кнопочка "сгенерить билдер", которая всё сделает, но это один раз, после этого — добавление нового поля требует бОльших усилий.
·>А что такое придумать, чтобы прям из коробки в ЯП было и было юзабельно и достаточно универсально — не очень ясно.
Ну, в дотнете это работает из коробки через Source Generators.
Вон, пару лет назад кто-то уже с этим игрался: https://justsimplycode.com/2020/12/06/auto-generate-builders-using-source-generator-in-net-5/
Наверняка к данному моменту уже есть более-менее отлаженная реализация.

Преимущество в том, что это никакие не хаки, а официально поддерживаемая технология. Интегрирована с интеллисенсом и билд-процессом.
Аннотировал нужный Record-класс атрибутом — и поехали.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 09.12.22 08:18
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Я не считаю, что .NET идет правильным путем, суя в язык как сорока всё блестящее.


С чего ты взял что это так? Если поинтересоваться процессом, то можно увидеть что реджектится огромное количество пропозалов, за каждым из которых часто стоит толпа людей, которые прям жить без этой фичи не могут.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 09.12.22 08:18
Оценка:
Здравствуйте, ·, Вы писали:

·>Суть в том, что api обычно уже имеет некое описание независимое от каких-либо ЯП.


Вот только часто такое API живет на стыке двух миров: REST и OOP, RDBMS и OOP, и т.п. У которых разные подходы, порождающие разные оптимальные модели. А вот генераторы модели не меняют и не адаптируют, в результате чего результат генерации сильно хуже оптимального.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Догонит ли net java?
От: · Великобритания  
Дата: 09.12.22 09:06
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Суть в том, что api обычно уже имеет некое описание независимое от каких-либо ЯП.

НС>Вот только часто такое API живет на стыке двух миров: REST и OOP, RDBMS и OOP, и т.п. У которых разные подходы, порождающие разные оптимальные модели.
Ну да. Если это не API напрямую подключаемой библиотеки на том же ЯП, то будет некая сериализация.

НС>А вот генераторы модели не меняют и не адаптируют, в результате чего результат генерации сильно хуже оптимального.

Вот это неясно. Генераторы выбирают и оптимизируют под условия. Если это rest и там принято json, то и оптимизировать в принципе нечего, тормозить будет безбожно в любом случае, зато human-friendly. А если нужна скорость, то берут protobuf или даже SBE и там всё до тактов вылизано, cache-friendly и т.п., на случай требований low-latency.
Более того, генераторы, как правило, можно подпиливать, для адаптации кода под условия.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 09.12.22 09:12
Оценка:
Здравствуйте, ·, Вы писали:

НС>>А вот генераторы модели не меняют и не адаптируют, в результате чего результат генерации сильно хуже оптимального.

·>Вот это неясно. Генераторы выбирают и оптимизируют под условия. Если это rest и там принято json, то и оптимизировать в принципе нечего, тормозить будет безбожно в любом случае, зато human-friendly. А если нужна скорость, то берут protobuf или даже SBE и там всё до тактов вылизано, cache-friendly и т.п., на случай требований low-latency.

Я писал не про оптимизации, а про оптимальность моделей. Реляционная модель отличается от ОО и напрямую ложится плохо. То же самое касаемо ОО и REST. В лучшем случае генераторы позволяют в полуручном режиме выходные модели допиливать, но чаще даже такой возможности нет, жри кактус.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: Догонит ли net java?
От: · Великобритания  
Дата: 09.12.22 09:22
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Вот это неясно. Генераторы выбирают и оптимизируют под условия. Если это rest и там принято json, то и оптимизировать в принципе нечего, тормозить будет безбожно в любом случае, зато human-friendly. А если нужна скорость, то берут protobuf или даже SBE и там всё до тактов вылизано, cache-friendly и т.п., на случай требований low-latency.

НС>Я писал не про оптимизации, а про оптимальность моделей. Реляционная модель отличается от ОО и напрямую ложится плохо. То же самое касаемо ОО и REST. В лучшем случае генераторы позволяют в полуручном режиме выходные модели допиливать, но чаще даже такой возможности нет, жри кактус.
Да всякое бывает. По ddl можно генерить код на ЯП, чтобы строить те же sql запросы с type-safety, без всякого ОО. И в случае rest то же — описываем структуру документа и генерим код, чтобы можно было удобно создавать json-документы, без всякого ОО. Какие варианты ещё в случае развесистых rest api? Строки клеить что-ли?

Ты, видимо, об ORM говоришь, неясно причём тут оно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 09.12.2022 9:23 · . Предыдущая версия .
Re[9]: Догонит ли net java?
От: vsb Казахстан  
Дата: 09.12.22 11:31
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>Я не считаю, что .NET идет правильным путем, суя в язык как сорока всё блестящее.


НС>С чего ты взял что это так? Если поинтересоваться процессом, то можно увидеть что реджектится огромное количество пропозалов, за каждым из которых часто стоит толпа людей, которые прям жить без этой фичи не могут.


Ну издалека оно так кажется. Когда в жаве, голанге и других языках годами вообще ничего существенного не добавляется, а в .NET каждый релиз куча новых фич.
Re[14]: Догонит ли net java?
От: · Великобритания  
Дата: 09.12.22 15:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Да всякое бывает. По ddl можно генерить код на ЯП, чтобы строить те же sql запросы с type-safety, без всякого ОО.

НС>Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака.
Whatever, другое api может иметь другое описание и по нему тоже генериться код.

НС>·>Ты, видимо, об ORM говоришь, неясно причём тут оно.

НС>Давай я тебе на простом примере продемонстрирую. Возьмем REST API и метод получения списка сущностей. Для одного типа сущностей мы, как правило, имеем один uri (часто это явно зафиксировано в гайдлайнах), и, как следствие, один метод контроллера сервиса. Если при этом мы имеем несколько разных юзкейсов, то сумма этих юзкейсов порождает набор фильтров в параметрах на все случаи жизни.
НС>Далее из этого автоматически генерируется OpenAPI spec (тут все еще ОК, потому что это все еще модель REST), а потом по ней клиент. И вот тут нам генератор породит и на клиенте метод-всемогутор, который, конечно, обладает максимальной гибкостью, но при этом еще и максимально неудобен, потому что нет ни одного юзкейса где нужны были бы все фильтры.
Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента. Сервер предоставляет общий api.

НС>И во вручную написанном клиенте вместо одного метода-всемогутера было бы N методов под каждый юзкейс.

Вручную — это как? Склейкой строк?

НС>Аналогичная ситуация и с классами-DTO.

И аналогичные подходы организации кода.

НС>Теоретически можно было бы обвесить метод контроллера метой, которая бы описывала юзкейсы, и которая передавалась бы в составе OpenAPI spec, а генератор эту мету доставал бы и генерил удобного клиента, но на практике я такого генератора не видел даже близко.

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

НС>Аналогичная ситуация и с ORM. Вся идея с тем, что мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API работает только на демках. Еще хуже работает когда эти POCO не вручную пишутся, а генерируются из схемы БД. Поэтому в реальности в лучшем случае только сабсет модели общий для всей цепочки, а полная модель у ORM, REST и клиента у каждого своя.

Это проблема SRP, а не кодогенерации. Если одну и ту же штуку пытаться впихнуть в два места, то ничего хорошего не выйдет.
У тебя есть модель субд, у тебя есть модель клиентов. По обоим моделям генерим код и пишем связывающую логику, используя все преимущества строгой типизации.

НС>Это я еще не вспоминаю про те же ad-hoc типы в ORM, которых в Java нет, но там где они есть это очень мощная штука.

Много лет уж как есть, с появления var можно и переменные присваивать, примерно так:
var thing = Stream.of(1, 2, 3)
        .map(i -> new Object() {final int twice = i * 2; final String str = "val" + i;})
        .filter(v -> v.twice > 3 && v.str.contains("3"))
        .findFirst()
        .orElseThrow();
System.out.println(thing.str);

Немного многословно, приходится типы полей прописывать, но вполне юзабельно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Догонит ли net java?
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.12.22 16:27
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот где сорочий подход, так это в Скале.

На скалу не смотрел, но в дотнете реально много что прямо таки достаёт.
Когда пишешь что-то типа from p in ... where p.Age > 42 select (p.Age, p.Name), а тебе в ответ "CS8143: An expression tree may not contain a tuple literal".
И там уже даже вроде бы решение придумали, которое всех бы устроило, но "this proposal isn't currently Championed which means that it's not being worked on by the team at this time."
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.12.22 18:00
Оценка:
Здравствуйте, ·, Вы писали:

·>
·>var thing = Stream.of(1, 2, 3)
·>        .map(i -> new Object() {final int twice = i * 2; final String str = "val" + i;})
·>        .filter(v -> v.twice > 3 && v.str.contains("3"))
·>        .findFirst()
·>        .orElseThrow();
·>System.out.println(thing.str);
·>

·>Немного многословно, приходится типы полей прописывать, но вполне юзабельно.
Кстати в Java завезли аналог IEnumerable c yield

То есть вызов осуществляется с права на лево как в C#?
и солнце б утром не вставало, когда бы не было меня
Re[16]: Догонит ли net java?
От: · Великобритания  
Дата: 09.12.22 20:25
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>·>Немного многословно, приходится типы полей прописывать, но вполне юзабельно.

S> Кстати в Java завезли аналог IEnumerable c yield
yield как конструкцию языка нет, не завезли. Другие средства есть на уровне библиотек, вроде хватает.

S>То есть вызов осуществляется с права на лево как в C#?

Классика map-reduce — вначале строится цепочка преобразований (flatmaps & Co) потом коллектор (reduce). Коллектор тащит всё через цепочку. Вроде слева направо. Не знаю что ты имеешь в виду "как в C#".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 10.12.22 15:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>И там уже даже вроде бы решение придумали, которое всех бы устроило, но "this proposal isn't currently Championed which means that it's not being worked on by the team at this time."


Ну так это обратная ситуация.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[15]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 10.12.22 15:56
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака.

·>Whatever, другое api может иметь другое описание и по нему тоже генериться код.

Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.

·>Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.


Но генератор тогда приносит минимум пользы, основное API приходится описывать руками.

НС>>И во вручную написанном клиенте вместо одного метода-всемогутера было бы N методов под каждый юзкейс.

·>Вручную — это как? Склейкой строк?

Вручную это вручную описывать методы. При чем тут склейка строк?

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


Нет, это ты почему то решил что есть какой то универсальный API сервера, который не имеет отношения к сценариям использования этого API.

НС>>Аналогичная ситуация и с ORM. Вся идея с тем, что мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API работает только на демках. Еще хуже работает когда эти POCO не вручную пишутся, а генерируются из схемы БД. Поэтому в реальности в лучшем случае только сабсет модели общий для всей цепочки, а полная модель у ORM, REST и клиента у каждого своя.

·>Это проблема SRP, а не кодогенерации.

Это проблема несовпадения разных моделей.

·>Если одну и ту же штуку пытаться впихнуть в два места, то ничего хорошего не выйдет.


Так твое предложение по единому описанию генерировать несколько моделей как раз такое впихивание и есть. Или ты предлагаешь для каждой модели свое описание и свой генератор?

·> .map(i -> new Object() {final int twice = i * 2; final String str = "val" + i;})


А чтобы свойства?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[16]: Догонит ли net java?
От: · Великобритания  
Дата: 10.12.22 17:54
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака.

НС>·>Whatever, другое api может иметь другое описание и по нему тоже генериться код.
НС>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.
Я говорю о language-agnostic спеке. Когда ты пишешь какой-нибудь rest api, то у тебя уже должна быть какая-то спека, которую ты выдаёшь консьюмерам api. Или ты предлагаешь отправлять исходники твоего сервера, чтобы они потом сами разбирались что твоё поделие делает? Или так, в pdf-ке пишешь, чтоб было с чем развлекаться?
Следовательно, если эта спека есть, то надо бы как-то проверить, что "просто написанная модель" этой спеке хоть как-то соответствует. Самый простой и прямой способ — сгенерить по спеке код, а не писать ещё одну модель и потом неясно как валидировать.

НС>·>Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.

НС>Но генератор тогда приносит минимум пользы, основное API приходится описывать руками.
Не API, а сценарии.

НС>>>И во вручную написанном клиенте вместо одного метода-всемогутера было бы N методов под каждый юзкейс.

НС>·>Вручную — это как? Склейкой строк?
НС>Вручную это вручную описывать методы. При чем тут склейка строк?
И что эти методы будут делать? Тебе по сути надо преобразовывать языковые конструкции в пачки байтов, в виде json/fix/protobuf/etc. Как именно это будет происходить?

НС>·>Потому что ты похоже путаешь сценарии конкретного клиента и API предоставляемый сервером, который должен уметь обслуживать различных клиентов.

НС>Нет, это ты почему то решил что есть какой то универсальный API сервера, который не имеет отношения к сценариям использования этого API.
Это не я решил, это ты сам так заявил: "имеем один uri (часто это явно зафиксировано в гайдлайнах), и, как следствие, один метод контроллера сервиса... на все случаи жизни".

НС>>>Аналогичная ситуация и с ORM. Вся идея с тем, что мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API работает только на демках. Еще хуже работает когда эти POCO не вручную пишутся, а генерируются из схемы БД. Поэтому в реальности в лучшем случае только сабсет модели общий для всей цепочки, а полная модель у ORM, REST и клиента у каждого своя.

НС>·>Это проблема SRP, а не кодогенерации.
НС>Это проблема несовпадения разных моделей.
Я об этом и говорю. Одну модель пытаешься впихнуть в два разных места. Это нарушение srp. Ну не надо так делать.

НС>·>Если одну и ту же штуку пытаться впихнуть в два места, то ничего хорошего не выйдет.

НС>Так твое предложение по единому описанию генерировать несколько моделей как раз такое впихивание и есть. Или ты предлагаешь для каждой модели свое описание и свой генератор?
Скажем, в условном приложении у тебя есть rest api с openapi и sql с каким-нибудь query-builder-ом. Ясен пень будет совершенно разные модели и свои генераторы.

НС>·> .map(i -> new Object() {final int twice = i * 2; final String str = "val" + i;})

НС>А чтобы свойства?
Не понял вопрос. Метод что-ли (что-то вроде new Object() {String calc(){return "calc" + i;}})? Или модифицируемое поле (просто убери final)?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 10.12.22 18:17
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.

·>Я говорю о language-agnostic спеке. Когда ты пишешь какой-нибудь rest api, то у тебя уже должна быть какая-то спека, которую ты выдаёшь консьюмерам api.

У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.

НС>>Но генератор тогда приносит минимум пользы, основное API приходится описывать руками.

·>Не API, а сценарии.

API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.

НС>>Вручную это вручную описывать методы. При чем тут склейка строк?

·>И что эти методы будут делать?

Непонятен вопрос.

·> Тебе по сути надо преобразовывать языковые конструкции в пачки байтов, в виде json/fix/protobuf/etc. Как именно это будет происходить?


Какое это имеет отношение к обсуждаемому вопросу?

НС>>Нет, это ты почему то решил что есть какой то универсальный API сервера, который не имеет отношения к сценариям использования этого API.

·>Это не я решил, это ты сам так заявил: "имеем один uri (часто это явно зафиксировано в гайдлайнах), и, как следствие, один метод контроллера сервиса... на все случаи жизни".

Я сказал совсем другое. REST API проектируется исходя из одного гайдлайна, структура БД — из другого, классы моделей — из третьего. Если одно генерировать из другого — неизбежны проблемы, потому что принципы проектирования не совпадают, а иногда даже противоречат друг другу.

НС>>Это проблема несовпадения разных моделей.

·>Я об этом и говорю. Одну модель пытаешься впихнуть в два разных места.

Это не я пытаюсь, это следствие попыток генерации нескольких моделей по одному описанию. Я говорю прямо обратное — модели эти должны быть разными.

НС>>Так твое предложение по единому описанию генерировать несколько моделей как раз такое впихивание и есть. Или ты предлагаешь для каждой модели свое описание и свой генератор?

·>Скажем, в условном приложении у тебя есть rest api с openapi и sql с каким-нибудь query-builder-ом. Ясен пень будет совершенно разные модели и свои генераторы.

Нет, не ясен. Я пока не понимаю что ты описываешь. Откуда берутся разные модели, что делает каждый из разных генераторов? Давай конкретно. Есть классический бэк RDBMS -> код бэка на Java/C# -> REST API -> код клиента на Java/C#/JS. Какие у тебя тут будут описания, генераторы и модели?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[18]: Догонит ли net java?
От: · Великобритания  
Дата: 10.12.22 18:38
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.

НС>·>Я говорю о language-agnostic спеке. Когда ты пишешь какой-нибудь rest api, то у тебя уже должна быть какая-то спека, которую ты выдаёшь консьюмерам api.
НС>У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.
Т.е. code-first, далеко не всегда работает, как минимумт только если ты вендор api. И посмотрел бы я на такой подход для, скажем, схемы субд.

НС>>>Но генератор тогда приносит минимум пользы, основное API приходится описывать руками.

НС>·>Не API, а сценарии.
НС>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.

НС>>>Вручную это вручную описывать методы. При чем тут склейка строк?

НС>·>И что эти методы будут делать?
НС>Непонятен вопрос.
Ну вот нужен тебе сервис для общения через protobuf. Что ты предлагаешь писать вручную?

НС>·> Тебе по сути надо преобразовывать языковые конструкции в пачки байтов, в виде json/fix/protobuf/etc. Как именно это будет происходить?

НС>Какое это имеет отношение к обсуждаемому вопросу?
Ты заявил, что ты собрался писать что-то вручную. Объясни как ты будешь писать тот же json вручную, да так, чтобы убедиться, что его другие могут вменяемо прочитать.

НС>>>Нет, это ты почему то решил что есть какой то универсальный API сервера, который не имеет отношения к сценариям использования этого API.

НС>·>Это не я решил, это ты сам так заявил: "имеем один uri (часто это явно зафиксировано в гайдлайнах), и, как следствие, один метод контроллера сервиса... на все случаи жизни".
НС>Я сказал совсем другое. REST API проектируется исходя из одного гайдлайна, структура БД — из другого, классы моделей — из третьего. Если одно генерировать из другого — неизбежны проблемы, потому что принципы проектирования не совпадают, а иногда даже противоречат друг другу.
Согласен. А кто-то пытается генерить бд из rest?!..

НС>>>Это проблема несовпадения разных моделей.

НС>·>Я об этом и говорю. Одну модель пытаешься впихнуть в два разных места.
НС>Это не я пытаюсь, это следствие попыток генерации нескольких моделей по одному описанию. Я говорю прямо обратное — модели эти должны быть разными.
Я не знаю кто так пытался и зачем. Может ты меня не так понял. Я предлагал иметь одно описание и генерить по нему код взаимодействующих участников. Т.е., например, по одному openapi генерить код и клиента, и сервера. сгенерённый код уже обмазывать реализующей логикой.

НС>>>Так твое предложение по единому описанию генерировать несколько моделей как раз такое впихивание и есть. Или ты предлагаешь для каждой модели свое описание и свой генератор?

НС>·>Скажем, в условном приложении у тебя есть rest api с openapi и sql с каким-нибудь query-builder-ом. Ясен пень будет совершенно разные модели и свои генераторы.
НС>Нет, не ясен. Я пока не понимаю что ты описываешь. Откуда берутся разные модели, что делает каждый из разных генераторов? Давай конкретно. Есть классический бэк RDBMS -> код бэка на Java/C# -> REST API -> код клиента на Java/C#/JS. Какие у тебя тут будут описания, генераторы и модели?
1. описание ddl для rdbms -> генерим код для бэка на java/c#
2. описание rest api (ну какой-нибудь openapi) генерим код для бэка на java/c#
3. Пишем логику бэка используя код сгенерённый в 1 и 2.
4. то же описание из 2 используем для генерапции клиентов на Java/C#/JS.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Догонит ли net java?
От: vsb Казахстан  
Дата: 11.12.22 04:20
Оценка:
Здравствуйте, iHateBrightVictories, Вы писали:

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


HBV>https://projectlombok.org/features/GetterSetter


Я про жаву а не про ломбок.
Re[2]: Догонит ли net java?
От: VladiCh  
Дата: 11.12.22 09:11
Оценка:
Здравствуйте, scf, Вы писали:

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


vaa>>Вот смотрю я на фичи java


scf>Сумбурно и мысль не очень понятна, но вот моё мнение: дотнет как язык С# и платформа лучше джавы, но никогда не догонит её по популярности, т.к. доверять бесплатным решениям Майкрософт дураков нет, и к платным тоже хватает вопросов.


Как язык лучше, как платформа — нет.
Re[3]: Догонит ли net java?
От: scf  
Дата: 11.12.22 09:13
Оценка:
Здравствуйте, VladiCh, Вы писали:

VC>Как язык лучше, как платформа — нет.


Почему? Модульность с пакетами-версиями-подписями лучше, есть предкомпиляция. Чем .net хуже jvm?
Re[2]: Догонит ли net java?
От: VladiCh  
Дата: 11.12.22 09:13
Оценка:
Здравствуйте, vsb, Вы писали:

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


vsb>Это всё, что надо знать про разработчиков языка.


Java расширябельная в некоторых пределах, если не хочешь использовать автоматическую генерацию геттеров/сеттеров, можно использовать например https://projectlombok.org/features/GetterSetter
Re[19]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 11.12.22 17:36
Оценка:
Здравствуйте, ·, Вы писали:

НС>>У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.

·>Т.е. code-first, далеко не всегда работает

А я и не говорил что работает всегда. Зато когда оно работает ...

НС>>>>Но генератор тогда приносит минимум пользы, основное API приходится описывать руками.

НС>>·>Не API, а сценарии.
НС>>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
·>Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.

Ничего не понял. API основанное на сценариях — частный случай?

НС>>>>Вручную это вручную описывать методы. При чем тут склейка строк?

НС>>·>И что эти методы будут делать?
НС>>Непонятен вопрос.
·>Ну вот нужен тебе сервис для общения через protobuf. Что ты предлагаешь писать вручную?

Я не понимаю какое это имеет отношение к разговору.

НС>>·> Тебе по сути надо преобразовывать языковые конструкции в пачки байтов, в виде json/fix/protobuf/etc. Как именно это будет происходить?

НС>>Какое это имеет отношение к обсуждаемому вопросу?
·>Ты заявил, что ты собрался писать что-то вручную. Объясни как ты будешь писать тот же json вручную

Я не заявлял что я собираюсь писать json вручную. Я говорил о классах модели.

·>1. описание ddl для rdbms -> генерим код для бэка на java/c#


Разные модели — раз.

·>2. описание rest api (ну какой-нибудь openapi) генерим код для бэка на java/c#


Разные модели — два.

·>4. то же описание из 2 используем для генерапции клиентов на Java/C#/JS.


НС>Это не я пытаюсь, это следствие попыток генерации нескольких моделей по одному описанию.
·>Я не знаю кто так пытался и зачем. Может ты меня не так понял.


... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 11.12.22 17:36
Оценка:
Здравствуйте, ·, Вы писали:

НС>>У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.

·>А вот
Автор: varenikAA
Дата: 07.09.20
и результат такого подхода.


Нет, это результат кривого генератора.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[21]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 11.12.22 19:27
Оценка:
Здравствуйте, ·, Вы писали:

НС>>>>У меня эта спека генерируется по классам контроллеров. Описание на C# — основное.

НС>>·>Т.е. code-first, далеко не всегда работает
НС>>А я и не говорил что работает всегда. Зато когда оно работает ...
·>Хреново оно работает.

Всегда хреново работает?

НС>>Нет, это результат кривого генератора.

·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически.
·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных.
·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание.

Ну вот, ты сам на все ответил.

·> Но зачем придумывать ещё один язык?..


Это наоборот, заставлять писать руками на OpenAPI это придумывать еще один язык.

НС>>·>Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.

НС>>Ничего не понял. API основанное на сценариях — частный случай?
·>Смотри мою эту цитату

Я ее уже смотрел. Это не отвечает на мои вопросы.

·> и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.".


Ну и? Какой тут бенефит от генератора?

НС>>·>Ну вот нужен тебе сервис для общения через protobuf. Что ты предлагаешь писать вручную?

НС>>Я не понимаю какое это имеет отношение к разговору.
·>Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю.

Я говорю о генерации моделей, я с самого начала про это написал. Генерировать сериализаторы, по крайней мере в дотнете, не нужно. Они сами справляются.

НС>>Я не заявлял что я собираюсь писать json вручную. Я говорил о классах модели.

·>Что за классы модели? И причём тут генерация кода?

Ты совсем потерял нить разговора?

vsb>Глаза закрывать? У меня есть файл, описывающий АПИ. В нём 5 строк кода, вызывающего что-то. В запросе/ответе по 30 полей, к примеру. Итого 65 строк осмысленного кода. И к этим 65 строкам прилагается 480 строк геттеров-сеттеров. И таких запросов, скажем, 20 штук. Лёгким движением руки из 1200 строк получаем 10 000.
·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.

При чем тут сериализация?

НС>>·>1. описание ddl для rdbms -> генерим код для бэка на java/c#

НС>>Разные модели — раз.
НС>>Разные модели — два.
·>Где что разное? Модели чего?

Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Догонит ли net java?
От: VladiCh  
Дата: 11.12.22 23:56
Оценка:
Здравствуйте, vsb, Вы писали:

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


HBV>>>>https://projectlombok.org/features/GetterSetter


vsb>>>Я про жаву а не про ломбок.


VC>>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.


vsb>Ломбок это отдельный язык. Похожий на Java, но это не Java. У Java-компилятора нет никаких плагинов. То, что он реализован, как annotation processing tool и в процессе вызова использует внутренние API компилятора через reflection и прочее — не делает его просто плагином. В Java нет разрешённого способа реализовать функционал ломбока без хаков. Lombok ломается при каждой крупной переработке внутренностей компилятора. И когда-нибудь сломается окончательно.


То что это annotation processing tool который работает compile time и делает его плагином к компилятору
Re[7]: Догонит ли net java?
От: vsb Казахстан  
Дата: 12.12.22 00:49
Оценка:
Здравствуйте, VladiCh, Вы писали:

vsb>>Ломбок это отдельный язык. Похожий на Java, но это не Java. У Java-компилятора нет никаких плагинов. То, что он реализован, как annotation processing tool и в процессе вызова использует внутренние API компилятора через reflection и прочее — не делает его просто плагином. В Java нет разрешённого способа реализовать функционал ломбока без хаков. Lombok ломается при каждой крупной переработке внутренностей компилятора. И когда-нибудь сломается окончательно.


VC>То что это annotation processing tool который работает compile time и делает его плагином к компилятору


У annotation processing tool есть определённый API. Этот API не позволяет делать то, что делает lombok. Чтобы lombok работал, используется хак в код компилятора.
Re[8]: Догонит ли net java?
От: VladiCh  
Дата: 12.12.22 02:00
Оценка:
Здравствуйте, vsb, Вы писали:

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


vsb>>>Ломбок это отдельный язык. Похожий на Java, но это не Java. У Java-компилятора нет никаких плагинов. То, что он реализован, как annotation processing tool и в процессе вызова использует внутренние API компилятора через reflection и прочее — не делает его просто плагином. В Java нет разрешённого способа реализовать функционал ломбока без хаков. Lombok ломается при каждой крупной переработке внутренностей компилятора. И когда-нибудь сломается окончательно.


VC>>То что это annotation processing tool который работает compile time и делает его плагином к компилятору


vsb>У annotation processing tool есть определённый API. Этот API не позволяет делать то, что делает lombok. Чтобы lombok работал, используется хак в код компилятора.


Это я понимаю. Я не понимаю почему ты считаешь что сам lombok это не плагин к компилятору. Пусть он и лезет в потроха самого компилятора чтобы делать то что он делает.
Отредактировано 12.12.2022 4:19 VladiCh . Предыдущая версия .
Re[7]: Догонит ли net java?
От: · Великобритания  
Дата: 12.12.22 08:27
Оценка:
Здравствуйте, VladiCh, Вы писали:

VC>>>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.

VC>·>Неправда.
VC>·>

Lombok is a huge hack that will only compile using javac or eclipse's compiler.

VC>·>Мы это уже тут обсудили выше и в качестве действительно стандартного решения я нашел https://github.com/Randgalt/record-builder
VC>Не понял, что в том что я сказал неправда? Используется стандартный механизм "JSR 269 Pluggable Annotation Processing API"
То что он делает, не укладывается в jsr269. К стандарту языка java это не имеет никакого отношения. С таким же успехом можно изобрести препроцессор javacpp и вызывать оттуда javac и обозвать это плагином, использующим стандартный javac.

VC>То что во внутренней логике у него хак на хаке — это здесь вторичное. Большинство стандартных билд механизмов поддерживается — https://projectlombok.org/contributing/lombok-execution-path

Тут даже написано, что для ecj вообще jsr269 не используется, а используется агент. И ещё требуется специальный плагин для IDE.
А действительно стандартное решение требует лишь поддержки jsr269 и всё. Ты можешь написать свою библиотеку, которая генерит код по jsr269 и она автоматом заработает везде. lombok же приходится подпиливать на каждую реализацию и иногда даже версию компилятора.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Догонит ли net java?
От: VladiCh  
Дата: 12.12.22 09:34
Оценка:
Здравствуйте, ·, Вы писали:

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


VC>>>>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное.

VC>>·>Неправда.
VC>>·>

Lombok is a huge hack that will only compile using javac or eclipse's compiler.

VC>>·>Мы это уже тут обсудили выше и в качестве действительно стандартного решения я нашел https://github.com/Randgalt/record-builder
VC>>Не понял, что в том что я сказал неправда? Используется стандартный механизм "JSR 269 Pluggable Annotation Processing API"
·>То что он делает, не укладывается в jsr269. К стандарту языка java это не имеет никакого отношения. С таким же успехом можно изобрести препроцессор javacpp и вызывать оттуда javac и обозвать это плагином, использующим стандартный javac.

VC>>То что во внутренней логике у него хак на хаке — это здесь вторичное. Большинство стандартных билд механизмов поддерживается — https://projectlombok.org/contributing/lombok-execution-path

·>Тут даже написано, что для ecj вообще jsr269 не используется, а используется агент. И ещё требуется специальный плагин для IDE.
·>А действительно стандартное решение требует лишь поддержки jsr269 и всё. Ты можешь написать свою библиотеку, которая генерит код по jsr269 и она автоматом заработает везде. lombok же приходится подпиливать на каждую реализацию и иногда даже версию компилятора.

Это все понятно, непонятно о чем здесь спор со мной. О том что нельзя Lombok назвать плагином к компилятору кажется? Тогда причем здесь "стандарт языка java"? Ты что-то додумываешь из того чего в моем сообщении не было. JSR 269 так и называется — Pluggable Annotation Processing API. Вызывается compile time. Только по этим критериям любой тул который использует этот API является плагином к компилятору, безотносительно того что он делает внутри. Все хаки и все такое прочее — это тоже побоку по большому счету. К рассматриваемому вопросу это имеет мало отношения. Lombok делает плюс минус то что и авто-проперти в C#, путем встраивания в "стандартный" javac через стандартный интерфейс + определенное нестандартное вуду с его внутренностями.
Re[9]: Догонит ли net java?
От: · Великобритания  
Дата: 12.12.22 10:25
Оценка:
Здравствуйте, VladiCh, Вы писали:

VC>·>А действительно стандартное решение требует лишь поддержки jsr269 и всё. Ты можешь написать свою библиотеку, которая генерит код по jsr269 и она автоматом заработает везде. lombok же приходится подпиливать на каждую реализацию и иногда даже версию компилятора.

VC>Это все понятно, непонятно о чем здесь спор со мной. О том что нельзя Lombok назвать плагином к компилятору кажется?
В лучшем случае его можно назвать плагином к oracle javac.

VC> Тогда причем здесь "стандарт языка java"? Ты что-то додумываешь из того чего в моем сообщении не было. JSR 269 так и называется — Pluggable Annotation Processing API. Вызывается compile time.

В случае eclipse compiler используется java agent судя по твоей же ссылке. А так же не может использоваться этот jsr в IDE, нужен специальный плагин.

VC> Только по этим критериям любой тул который использует этот API является плагином к компилятору, безотносительно того что он делает внутри. Все хаки и все такое прочее — это тоже побоку по большому счету. К рассматриваемому вопросу это имеет мало отношения. Lombok делает плюс минус то что и авто-проперти в C#, путем встраивания в "стандартный" javac через стандартный интерфейс + определенное нестандартное вуду с его внутренностями.

То что Остап Бендер заявляет, что чтит уголовный кодекс, не делает его законопослушным гражданином.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.12.22 13:02
Оценка:
Здравствуйте, ·, Вы писали:

НС>>А я и не говорил что работает всегда. Зато когда оно работает ...

·>Хреново оно работает.

Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов. Во вторых, меньше интеграционного кода, меньше шансов сломать. В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.

·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически.


2023й год на дворе, очнись.

·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных.


Метаданные у вас не изобрели, понимаю.

·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание. Но зачем придумывать ещё один язык?..


Не надо изобретать — есть декларативные способы задания аспектов апи. Работают сами по себе, без приседаний. Они выдают метаданные. Подхватил метаданные — нагенерил хучь что хошь. Можешь генерить и тесты, и клиент, и солюшн для нового приложения, хоть скрипты деплоймента.
Манифест типа OpenAPI должен генерироватся каким протестированым надежным генератором по метаданным. Т.е. не руками писаться, а генерироваться!
Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.
Отредактировано 12.12.2022 13:04 Pauel . Предыдущая версия .
Re[22]: Догонит ли net java?
От: · Великобритания  
Дата: 12.12.22 14:16
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Хреново оно работает.

НС>Всегда хреново работает?
Угу. Другое дело, что иногда хреновый результат может быть всё ещё годным на практике.

НС>>>Нет, это результат кривого генератора.

НС>·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически.
НС>·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных.
НС>·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание.
НС>Ну вот, ты сам на все ответил.
Ага. Ведь гланды можно удалять через разные места.

НС>·> Но зачем придумывать ещё один язык?..

НС>Это наоборот, заставлять писать руками на OpenAPI это придумывать еще один язык.
OpenAPI это уже существующий и стандартизованный язык. Не надо его придумывать. То же самое и для других случаев типа fix, avro, protobuf и т.п.

НС>>>·>Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.

НС>>>Ничего не понял. API основанное на сценариях — частный случай?
НС>·>Смотри мою эту цитату
НС>Я ее уже смотрел. Это не отвечает на мои вопросы.
Ок. Отвечаю на этот вопрос: "API основанное на сценариях — частный случай?"
Понятия не имею откуда ты это взял и почему ты задаёшь мне этот вопрос, и коньяк я не пью по утрам.

НС>·> и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.".

НС>Ну и? Какой тут бенефит от генератора?
В том, что писать будешь используя сгенерированный код, имея все преимущества стротипизированного кода, а не писать всё с нуля.

НС>>>·>Ну вот нужен тебе сервис для общения через protobuf. Что ты предлагаешь писать вручную?

НС>>>Я не понимаю какое это имеет отношение к разговору.
НС>·>Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю.
НС>Я говорю о генерации моделей, я с самого начала про это написал. Генерировать сериализаторы, по крайней мере в дотнете, не нужно. Они сами справляются.
Что такое генерация моделей? И с какой целью их генерировать?

НС>>>Я не заявлял что я собираюсь писать json вручную. Я говорил о классах модели.

НС>·>Что за классы модели? И причём тут генерация кода?
НС>Ты совсем потерял нить разговора?
НС>

vsb>>Глаза закрывать? У меня есть файл, описывающий АПИ. В нём 5 строк кода, вызывающего что-то. В запросе/ответе по 30 полей, к примеру. Итого 65 строк осмысленного кода. И к этим 65 строкам прилагается 480 строк геттеров-сеттеров. И таких запросов, скажем, 20 штук. Лёгким движением руки из 1200 строк получаем 10 000.
НС>·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.

НС>При чем тут сериализация?
Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации.

НС>>>Разные модели — раз.

НС>>>Разные модели — два.
НС>·>Где что разное? Модели чего?
НС>Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал.
Модели чего разные? Преобразовать чего к чему? Говори конкретно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Догонит ли net java?
От: · Великобритания  
Дата: 12.12.22 14:28
Оценка:
Здравствуйте, Pauel, Вы писали:

НС>>>А я и не говорил что работает всегда. Зато когда оно работает ...

P>·>Хреново оно работает.
P>Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов.
Ага-ага. И поэтому у вас всё постоянно валится и вам приходится в проде тестировать.

P>Во вторых, меньше интеграционного кода, меньше шансов сломать.

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

P>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.

Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.

P>·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически.

P> 2023й год на дворе, очнись.
Ну математические теоремы ещё не научились опровергать.

P>·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных.

P>Метаданные у вас не изобрели, понимаю.
Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.

P>·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание. Но зачем придумывать ещё один язык?..

P>Не надо изобретать — есть декларативные способы задания аспектов апи.
Где они есть-то? Ссылочку на стандарт можно?

P>Работают сами по себе, без приседаний. Они выдают метаданные. Подхватил метаданные — нагенерил хучь что хошь. Можешь генерить и тесты, и клиент, и солюшн для нового приложения, хоть скрипты деплоймента.

P>Манифест типа OpenAPI должен генерироватся каким протестированым надежным генератором по метаданным. Т.е. не руками писаться, а генерироваться!
P>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.
Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[23]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 12.12.22 16:16
Оценка:
Здравствуйте, ·, Вы писали:

НС>>·>Хреново оно работает.

НС>>Всегда хреново работает?
·>Угу.

Сильное заявление. Обоснования будут?

НС>>Ну вот, ты сам на все ответил.

·>Ага. Ведь гланды можно удалять через разные места.

Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает.

НС>>Это наоборот, заставлять писать руками на OpenAPI это придумывать еще один язык.

·>OpenAPI это уже существующий и стандартизованный язык.

Тем не менее это еще один язык.

НС>>Я ее уже смотрел. Это не отвечает на мои вопросы.

·>Ок. Отвечаю на этот вопрос: "API основанное на сценариях — частный случай?"
·>Понятия не имею откуда ты это взял

НС>>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
·> Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.
НС> Ничего не понял. API основанное на сценариях — частный случай?


НС>>·> и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.".

НС>>Ну и? Какой тут бенефит от генератора?
·>В том, что писать будешь используя сгенерированный код

В чем бенефит?

·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.


Что нужно писать с нуля и почему? Почему не хватает средств реюза языка и нужен генератор?

НС>>·>Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю.

НС>>Я говорю о генерации моделей, я с самого начала про это написал. Генерировать сериализаторы, по крайней мере в дотнете, не нужно. Они сами справляются.
·>Что такое генерация моделей?

Генерация классов C#/Java по какому то внешнему описанию не на C#/Java.

·> И с какой целью их генерировать?


Для описания метаданных в терминах компилятора строго типизированных язков.

·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации.


Нет конечно.

НС>>Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал.

·>Модели чего разные? Преобразовать чего к чему? Говори конкретно.

Конкретные примеры я уже приводил.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[23]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.12.22 17:44
Оценка:
Здравствуйте, ·, Вы писали:

P>>Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов.

·>Ага-ага. И поэтому у вас всё постоянно валится и вам приходится в проде тестировать.

Тесты в проде это признак отсутствия синдрома бога.

P>>Во вторых, меньше интеграционного кода, меньше шансов сломать.

·>Потому что вы заблуждаетесь, что навешанные аннотации это не код и можно не тестировать.

Наоборот, нужно, только не надо дублировать 100500 тестов либы которая для этого испольуется.

> На самом деле, каждая повешанная аннотация — это точно такой же код, как и всё остальное, и требует соответствующих тестов.


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

P>>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.

·>Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.

Цикл разработки версии — месяцы, иногда и годы. И нужен быстрый способ менять апи в разработке.

·>Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.


А ты похоже не в курсе, что нет полноценного grpc для веба, т.к. браузер и особенно приложение унутре, не контролируют полностью протокол хттп. А вот где грпц играет — в изолированой сети, когда созданы специальные условия.

P>>Не надо изобретать — есть декларативные способы задания аспектов апи.

·>Где они есть-то? Ссылочку на стандарт можно?

grpcs это один из таких вариантов. Одна проблема — для веба не летает. А потому фремворки умеют все эти вещи.
еще есть graphql. И много чего есть. Фичи конкретного фремворка это эквивалентное решение.

P>>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.

·>Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.

Пока что эта сила в веб вылезть не может. грпц это круто, только что делать в вебе? есть grpc-web, но это костыль и он убог.

Теоретически, когда grpc вылезет из своей конуры, это будет прорыв в вебе. Но шота предпосылок к этому не имеется.
Re[24]: Догонит ли net java?
От: · Великобритания  
Дата: 12.12.22 20:31
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Во вторых, меньше интеграционного кода, меньше шансов сломать.

P>·>Потому что вы заблуждаетесь, что навешанные аннотации это не код и можно не тестировать.
P>Наоборот, нужно, только не надо дублировать 100500 тестов либы которая для этого испольуется.
Если у тебя в c#-коде сервер есть аннотация [Header("blah")], то где-то в js-коде клиента надо будет интеграционно тестировать, что это именно этот хедер именно с этим именем именно на этом параметре. И так надо для каждого параметра и метода, и для каждой реализации клиента. В случае же если у вас будет написана спека openapi, то вам достаточно проверить, что клиент и сервер используют одинаковую спеку (банально сравнить контрольную сумму). В худшем случае протестировать совместимость пар версий спек (часто это можно сделать алгоритмически, см avro schema evolution rules).
Справедливо заметить, что всё равно нужно будет тестировать логику в любом случае, но, по крайней мере, 90% случаев интеграции хотя бы по типам и структуре данных это покроет (ту самую проблему, с которой тут началось обсуждение о dto-шках с 40 полями).

>> На самом деле, каждая повешанная аннотация — это точно такой же код, как и всё остальное, и требует соответствующих тестов.

P>Парсер формата .proto тоже требует тестов.
Это не ваша забота. Этим занимаются инженеры гугла и тестируется всем миром.

P>И это сторонняя либа. Соответсвенно в продукте нет необходимости заниматься дурью и дублирвать все тесты подобного рода.

P>А вот тесты апи всё равно надо делать, не важно чем ты это апи пропишешь. Или у вас и таких тестов тоже нет?
Если оба потребителя апи используют ту же спеку, то они совместимы by-design.
Т.е. вы можете тестировать свой c#-сервер используя тестовый c#-клиент. А реальные пользователи могут использовать js-клиент, если он по той же спеке.

P>>>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.

P>·>Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.
P>Цикл разработки версии — месяцы, иногда и годы. И нужен быстрый способ менять апи в разработке.
Ну так в том же openapi это переместить парам из "in: query" в "in: header" и собственно всё. Сгеренённые сигнатуры методов, скорее всего, и не поменяются.

P>·>Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.

P>А ты похоже не в курсе, что нет полноценного grpc для веба, т.к. браузер и особенно приложение унутре, не контролируют полностью протокол хттп. А вот где грпц играет — в изолированой сети, когда созданы специальные условия.
Во-первых, в курсе. Во-вторых, и чё? В-третьих, rest это вовсе не означает, что непременно браузер. В-четвёртых, это просто пример. Пусть будет openapi вместо gprc, суть моего тезиса не менятеся.

P>>>Не надо изобретать — есть декларативные способы задания аспектов апи.

P>·>Где они есть-то? Ссылочку на стандарт можно?
P>grpcs это один из таких вариантов. Одна проблема — для веба не летает. А потому фремворки умеют все эти вещи.
P>еще есть graphql. И много чего есть. Фичи конкретного фремворка это эквивалентное решение.
Не очень понял. Какие именно "декларативные способы задания аспектов апи" ты имел в виду?

P>>>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.

P>·>Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.
P>Пока что эта сила в веб вылезть не может. грпц это круто, только что делать в вебе? есть grpc-web, но это костыль и он убог.
P>Теоретически, когда grpc вылезет из своей конуры, это будет прорыв в вебе. Но шота предпосылок к этому не имеется.
Потому что всем интересно изобретение фреймворков на аннотациях для своих любимых яп, побыстрому колбасят code-first, получить бонус и потом тратят время и деньги заказчиков на "писать клиентов нужно руками".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 12.12.2022 21:30 · . Предыдущая версия .
Re[25]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 13.12.22 09:28
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Сильное заявление. Обоснования будут?

·>Вот же
Автор: varenikAA
Дата: 07.09.20
, выше уже приводил. Не можете даже шарп из шарпа заюзать, в итоге "писать клиентов нужно руками".


Единичный баг как обоснование заявления с квантором всеобщности?

НС>>Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает.

·>Нет никакого богом данного языка описания модели

Зато есть основной рабочий язык разработчика.

НС>>Тем не менее это еще один язык.

·>В моей схеме это второй и последний язык,

Только в одном маленьком аспекте.

·>Только ты пытаешься генерить на этом языке из твоих аннотаций, которые по сути edsl, т.е. третий язык.


Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.

НС>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.

НС>>Что нужно писать с нуля и почему?
·>Вот по твоему же заявлению: "писать клиентов нужно руками".

И где здесь "с нуля"?

НС>>Почему не хватает средств реюза языка и нужен генератор?

·>Пусть дали тебе .proto-файл.

Пусть мне не давали .proto файл.

НС>>·>Что такое генерация моделей?

НС>>Генерация классов C#/Java по какому то внешнему описанию не на C#/Java.
·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?

В том и проблема, что модель получается одна, хотя нужны разные.

НС>>·> И с какой целью их генерировать?

НС>>Для описания метаданных в терминах компилятора строго типизированных язков.
·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?

Метаданные .NET -> генератор -> OpenAPI spec

НС>>·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации.

НС>>Нет конечно.
·>Почему?

Потому что спецификация API это намного больше чем просто сериализация.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[17]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 13.12.22 09:29
Оценка:
Здравствуйте, Gt_, Вы писали:

НС>>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.

Gt_>а как предлагается написать модель, если требуется два вида табличек — основная и историческая ? историческую наследовать от основной ?

Не понимаю какое это имеет оношение к обсуждаемому вопросу.

Gt_>а как там у орм потом с планами не поедет крыша от наследований ?


Ты меня с кем то перепутал. Я наоборот предлагал наследование не использовать по возможности.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[18]: Догонит ли net java?
От: Gt_  
Дата: 13.12.22 10:12
Оценка:
НС>>>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.
Gt_>>а как предлагается написать модель, если требуется два вида табличек — основная и историческая ? историческую наследовать от основной ?

НС>Не понимаю какое это имеет оношение к обсуждаемому вопросу.


Gt_>>а как там у орм потом с планами не поедет крыша от наследований ?


НС>Ты меня с кем то перепутал. Я наоборот предлагал наследование не использовать по возможности.


я ничего не путаю, именно ты собрался в рукопашную писать модели, пользуясь выразительностью языка (тм)
по мне, так очень необычный подход. потому и спрашиваю, вот в случае основной и исторической таблички, что предлагается — пользоваться той самой выразительностью языка и наследовать ? может для каждого понятие врукопашную перестукивать все поля, сначала для основной, потом для исторической ? пока это вопрос, понять, что в противовес DSL языку предлагается.
Отредактировано 13.12.2022 10:13 Gt_ . Предыдущая версия .
Re[26]: Догонит ли net java?
От: · Великобритания  
Дата: 13.12.22 11:41
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Сильное заявление. Обоснования будут?

НС>·>Вот же
Автор: varenikAA
Дата: 07.09.20
, выше уже приводил. Не можете даже шарп из шарпа заюзать, в итоге "писать клиентов нужно руками".

НС>Единичный баг как обоснование заявления с квантором всеобщности?
"В свое время перебрали пачку генераторов" — вполне таки квантор всеобщности. Или ты имел в виду клиенты для этого конкретного сервиса? Или за два года этот самый единичный баг поправили наконец?

НС>>>Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает.

НС>·>Нет никакого богом данного языка описания модели
НС>Зато есть основной рабочий язык разработчика.
Ты говоришь о каком-то игрушечном проекте, видимо. В реальности одним ЯП ну никак не обойтись.

НС>>>Тем не менее это еще один язык.

НС>·>В моей схеме это второй и последний язык,
НС>Только в одном маленьком аспекте.
Что?

НС>·>Только ты пытаешься генерить на этом языке из твоих аннотаций, которые по сути edsl, т.е. третий язык.

НС>Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.
Т.е. ты хочешь сказать, что можно наколбасить произвольный c# код и любому коду некий генератор может сгенерить юзабельную схему? Имя генератора в студию!

НС>>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.

НС>>>Что нужно писать с нуля и почему?
НС>·>Вот по твоему же заявлению: "писать клиентов нужно руками".
НС>И где здесь "с нуля"?
А с чего?

НС>>>Генерация классов C#/Java по какому то внешнему описанию не на C#/Java.

НС>·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?
НС>В том и проблема, что модель получается одна, хотя нужны разные.
Разные модели чего? где? и для чего?

НС>>>Для описания метаданных в терминах компилятора строго типизированных язков.

НС>·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?
НС>Метаданные .NET ->
Подробнее, что такое "Метаданные .NET"? Аннотации?

НС> генератор -> OpenAPI spec

Ок, ну допустим. А дальше? "писать клиентов нужно руками"?

НС>>>·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации.

НС>>>Нет конечно.
НС>·>Почему?
НС>Потому что спецификация API это намного больше чем просто сериализация.
Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией, поэтому в контексте обсуждения это таки сериализация.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 13.12.22 18:28
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Зато есть основной рабочий язык разработчика.

·>Ты говоришь о каком-то игрушечном проекте, видимо. В реальности одним ЯП ну никак не обойтись.

Где я написал, что обойтись? Но чем меньше языков, тем лучше.

НС>>Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.

·>Т.е. ты хочешь сказать, что можно наколбасить произвольный c# код и любому коду некий генератор может сгенерить юзабельную схему?

Что значит произвольный? Схема генерится по вполне определенным классам контроллеров. И да, вполне можно обойтись без специальной разметки для OpenAPI. Можно и вообще без разметки.

·>Имя генератора в студию!


Swashbuckle.

НС>>>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.

НС>>>>Что нужно писать с нуля и почему?
НС>>·>Вот по твоему же заявлению: "писать клиентов нужно руками".
НС>>И где здесь "с нуля"?
·>А с чего?

Со всего что позволяет язык.

НС>>·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?

НС>>В том и проблема, что модель получается одна, хотя нужны разные.
·>Разные модели чего? где? и для чего?

Ответ на это я уже много раз давал. По кругу ходить не собираюсь.

НС>>·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?

НС>>Метаданные .NET ->
·>Подробнее, что такое "Метаданные .NET"? Аннотации?

In general, a static assembly can consist of four elements:

The assembly manifest, which contains assembly metadata.
Type metadata.

Microsoft intermediate language (MSIL) code that implements the types. It is generated by the compiler from one or more source code files.
A set of resources.

https://learn.microsoft.com/en-us/dotnet/standard/assembly/contents

НС>> генератор -> OpenAPI spec

·>Ок, ну допустим. А дальше?

Что дальше?

·>"писать клиентов нужно руками"?


Да, контракт клиента лучше описать руками. Но это не означает что нужно каждый раз все писать с нуля, генераторы это далеко не единственный способ реюза кода.

НС>>Потому что спецификация API это намного больше чем просто сериализация.

·>Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией

Нет конечно. Дтошки это прежде всего контракт, сериализация вторична. По одной и той же модели, к примеру, искаропки есть json и xml. В gRPC, разумеется, в силу его особенностей, приходится использовать protoc, но это именно его личная особенность.
А вот извив ума, по которому свойства в DTO оказывается нужны исключительно для сериализации — это тоже очень смелый подход к логике.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 13.12.22 18:31
Оценка:
Здравствуйте, Gt_, Вы писали:

НС>>Ты меня с кем то перепутал. Я наоборот предлагал наследование не использовать по возможности.


Gt_>я ничего не путаю, именно ты собрался в рукопашную писать модели, пользуясь выразительностью языка (тм)


И при чем тут наследование? Наследование в том же REST — редкостный геморой.

Gt_>по мне, так очень необычный подход.


Ну это по тебе. А так очень распространенный подход.

Gt_>вот в случае основной и исторической таблички


Мужик, я понятия не имею про твою специфику. И, если честно, желания вникать в нее нет. Делай как тебе удобнее.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[28]: Догонит ли net java?
От: · Великобритания  
Дата: 13.12.22 22:19
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Где я написал, что обойтись? Но чем меньше языков, тем лучше.

Ага. И только у тебя получается, что три меньше двух.

НС>>>Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.

НС>·>Т.е. ты хочешь сказать, что можно наколбасить произвольный c# код и любому коду некий генератор может сгенерить юзабельную схему?
НС>Что значит произвольный? Схема генерится по вполне определенным классам контроллеров. И да, вполне можно обойтись без специальной разметки для OpenAPI. Можно и вообще без разметки.
Ок, уже теплее. Как эти классы контроллеров определяются? Как определяется что пойдёт в хедер, что в квери и т.п.? Ответ тут:

НС>Swashbuckle.

  Вот если это не EDSL, то я папа римский.
builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("v1", new OpenApiInfo
    {
        Version = "v1",
        Title = "ToDo API",
        Description = "An ASP.NET Core Web API for managing ToDo items",
        TermsOfService = new Uri("https://example.com/terms"),
        Contact = new OpenApiContact
        {
            Name = "Example Contact",
            Url = new Uri("https://example.com/contact")
        },
        License = new OpenApiLicense
        {
            Name = "Example License",
            Url = new Uri("https://example.com/license")
        }
    });
});
...
[HttpDelete("{id}")]
[ProducesResponseType(StatusCodes.Status201Created)]
[ProducesResponseType(StatusCodes.Status400BadRequest)]
[Required]
[DefaultValue(false)]
[ApiController]
[Route("api/[controller]")]
[Produces("application/json")]

Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх.

НС>>>>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.

НС>>>>>Что нужно писать с нуля и почему?
НС>>>·>Вот по твоему же заявлению: "писать клиентов нужно руками".
НС>>>И где здесь "с нуля"?
НС>·>А с чего?
НС>Со всего что позволяет язык.
Словоблудие.

НС>>>·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?

НС>>>В том и проблема, что модель получается одна, хотя нужны разные.
НС>·>Разные модели чего? где? и для чего?
НС>Ответ на это я уже много раз давал. По кругу ходить не собираюсь.
Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM и в REST. Конечно, так делать не надо, и я такое никогда не предлагал. Точнее я ответ твой понял, но он был не в тему.
"Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал." — кто "мы" пытается модели преобразовывать генератором? Каким генератором? Зачем вообще преобразовывать модели генератором?

Может ты плохо представляешь как это работает? Вот конкретный пример:
1. пишем openapi спеку
2. Запускаем генератор, получаем "рыбу" — набор interface с методами и классы для dto-шек. Эту рыбу можно запаковать как отдельную либу (в принципе необязательно, код можно генерировать и по месту использования).
  нагенерится как-то так
@Generated
class UserDto {
  private String id;
  private String name;
  String getName() {...};
  void setName(String name){...};
}
@Generated
interface UserApi {
  UserDto getUserByName(String name);
}

всё это дело будет густо обвешано аннотациями и кусками кода для всяких дефолтных значений, валидаций, маппингов на урлы-хедеры-етс. То что ты пишешь ручками в виде [DefaultValue(false)] и [HttpDelete("{id}")].

3. На сервере подключаем эту либу и реализуем интерфейсы как классы контроллеров.
  пишем как-то так
class UserController implements UserApi {
  @Override UserDto getUserByName(String name) {return new UserDto(...);}
}
httpServer.handle(new UserController(...));

4. На клиенте подключаем эту же либу и используем эти же интерфейсы, чтобы дёргать сервер.
  пишем как-то так
var rest = new RestClient("http://server.address...");
var userApi = rest.getUserApi();
var userDto = userApi.getUserByName("vasya");

5. всё.

Тебе нужно знать два языка — язык спеки openapi и язык программирования java. Никаких аннотаций писать не надо, изучать никаких библиотек не надо, максимум несколько опций генератора задать в настройках проекта.
Дальше по той же спеке можно генерить "рыбу" для javascript/typescript в браузере и т.п. А если захочется переписать кусочек сервера на scala/kotlin/etc — можно использовать соответствующий генератор для генерации более language-friendly рыбы.

Мода на code-first в java была лет 10-15 назад... Врочем и сейчас может использоваться в мелких проектах — запилить и забыть. А для дотнета наконец-то настал "2023й год на дворе, очнись"...

НС>>>·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?

НС>>>Метаданные .NET ->
НС>·>Подробнее, что такое "Метаданные .NET"? Аннотации?
НС>https://learn.microsoft.com/en-us/dotnet/standard/assembly/contents
Вот эти метаданные и аннотации и должны описываться неким формальным языком, чтобы генератор мог работать и выдавать что-то вменяемое.

НС>>> генератор -> OpenAPI spec

НС>·>Ок, ну допустим. А дальше?
НС>Что дальше?
Ну сгенерили мы OpenAPI spec. Как и любой сгенерённый код она практически не человекочитаема, тулзы переваривать нормально не умеют... И накой? Что дальше с ней делать?

НС>·>"писать клиентов нужно руками"?

НС>Да, контракт клиента лучше описать руками. Но это не означает что нужно каждый раз все писать с нуля, генераторы это далеко не единственный способ реюза кода.
Почему лучше? Какие способы реюза ты предлагаешь?

НС>>>Потому что спецификация API это намного больше чем просто сериализация.

НС>·>Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией
НС>Нет конечно. Дтошки это прежде всего контракт, сериализация вторична.
Вторична да. Но в контексте дтошек в 40 полей это и есть — передать развесистый документ между системами — сериализовать по спеке, прогнать байтики, десериализовать. Что собственно сгенерированный из спек код и делает в основном.

НС> По одной и той же модели, к примеру, искаропки есть json и xml. В gRPC, разумеется, в силу его особенностей, приходится использовать protoc, но это именно его личная особенность.

Такая же личная особенность есть в thrift, avro, sbe, fix, asn.1 и т.п.

НС>А вот извив ума, по которому свойства в DTO оказывается нужны исключительно для сериализации — это тоже очень смелый подход к логике.

Согласен. Не извивайся так больше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 14.12.22 11:53
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Swashbuckle.

·>[cut=Вот если это не EDSL, то я папа римский.]

Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.

·>Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх.


Перешел на личности — слил.

НС>>Ответ на это я уже много раз давал. По кругу ходить не собираюсь.

·>Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM


Аргументы, похоже кончились. Началось хамство и подтасовки. На сем стоит закончить.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[30]: Догонит ли net java?
От: · Великобритания  
Дата: 14.12.22 13:17
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Swashbuckle.

НС>·>[cut=Вот если это не EDSL, то я папа римский.]
НС>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.
Какая разница? asp.net это не c# язык, а большой фреймворк со своим edsl который тоже надо знать и учить.

НС>·>Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх.

НС>Перешел на личности — слил.
whatever.

НС>>>Ответ на это я уже много раз давал. По кругу ходить не собираюсь.

НС>·>Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM
НС>
НС>Аргументы, похоже кончились. Началось хамство и подтасовки. На сем стоит закончить.
Где ты тут увидел хамство и подтасовки?
Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было. Я никогда не предлагал ничего подобного.
Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 14.12.22 13:35
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.

·>Какая разница?

Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.

НС>>·>Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх.

НС>>Перешел на личности — слил.
·>whatever.

НС>>·>Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM

НС>>
НС>>Аргументы, похоже кончились. Началось хамство и подтасовки. На сем стоит закончить.
·>Где ты тут увидел хамство

Там где ты перешел на личности.

·>Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было.


К твоим вопросам про то где там генерация нескольких моделей поодному описанию.

·>Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.


Нет, это называется замыливание исходной темы. Ты уже куда только не пытался с нее сползти.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[32]: Догонит ли net java?
От: · Великобритания  
Дата: 14.12.22 13:53
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.

НС>·>Какая разница?
НС>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.
Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot, оно нагенерит соответсвующие аннотации. С т.з. программиста нужно лишь знать, как в яп классы имплементируют интерфейсы, никакой разметки.
Вот эта вся колбаса сгенерирована:
@javax.annotation.Generated(...)
@Controller
@RequestMapping("${openapi.reflectoring.base-path:/v2}")
public class UserApiController implements UserApi {


https://reflectoring.io/spring-boot-openapi/

Если шарп это не умеет, то сабж.

НС>·>Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было.

НС>К твоим вопросам про то где там генерация нескольких моделей поодному описанию.
Ты сам придумал генерацию нескольких моделей по одному описанию. У меня такого не было, вот я и спрашивал откуда ты это взял.

НС>·>Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.

НС>Нет, это называется замыливание исходной темы. Ты уже куда только не пытался с нее сползти.
Исходная тема — дтошка с 40 полями, а не генерация нескольких моделей из одного описания.

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

Где у FIX, ...etc несколько моделей?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 14.12.2022 13:57 · . Предыдущая версия .
Re[33]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.12.22 14:06
Оценка:
Здравствуйте, ·, Вы писали:

https://learn.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-6.0&amp;tabs=visual-studio
Вобще то много чего есть. Даже summary берет
и солнце б утром не вставало, когда бы не было меня
Re[34]: Догонит ли net java?
От: · Великобритания  
Дата: 14.12.22 14:14
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>https://learn.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-6.0&amp;tabs=visual-studio

S>Вобще то много чего есть. Даже summary берет
Как я вижу, оно не умеет серверный код генерить. Вот вы и мучаетесь. Сабж...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[35]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.12.22 14:40
Оценка:
Здравствуйте, ·, Вы писали:

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


S>>https://learn.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-6.0&amp;tabs=visual-studio

S>>Вобще то много чего есть. Даже summary берет
·>Как я вижу, оно не умеет серверный код генерить. Вот вы и мучаетесь. Сабж...
Какой такой серверный код? Есть Source Generator. Можно, что угодно нагенерить!
и солнце б утром не вставало, когда бы не было меня
Re[36]: Догонит ли net java?
От: · Великобритания  
Дата: 14.12.22 15:15
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Вобще то много чего есть. Даже summary берет

S>·>Как я вижу, оно не умеет серверный код генерить. Вот вы и мучаетесь. Сабж...
S>Какой такой серверный код?
Ну например, создать заготовку rest-сервера по openapi спеке, в которую останется вписать код имплементации методов.

S>Есть Source Generator. Можно, что угодно нагенерить!

Новости из будущего? Вот когда нагенерите, тогда приходите, может сабж и случится.
Впрочем, вижу вот целых 2 месяца назад наконец-то появилась какая-то поделка https://github.com/s-tarasov/ST.NSwag.ServerSourceGenerator
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Догонит ли net java?
От: · Великобритания  
Дата: 14.12.22 15:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Есть Source Generator. Можно, что угодно нагенерить!

S>·>Новости из будущего? Вот когда нагенерите, тогда приходите, может сабж и случится.
S>·>Впрочем, вижу вот целых 2 месяца назад наконец-то появилась какая-то поделка https://github.com/s-tarasov/ST.NSwag.ServerSourceGenerator
S> По уму там и Source Generator не нужен. Он нужен только для модель изменяемая.
Ну rest спеки меняются иногда, да.

S> А так я не вижу проблем. Можно и самому по модели методы написать

Как именно написать? Вручную? Как потом валидировать, что написанное соответствует спеке?

S> и DTO сгенерить. Не вижу каких то проблем.

Как сгенерить-то?

S> Только странно как то из описания генерить сервер. Больше нужен клиент.

И то, и то нужно. В этом и сила, что клиент и сервер генерятся на основе одной и той же спеки, что гарантирует их совместимость. Притом разные части api можно реализовывать на разном стеке технологий в зависимости от требований.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[39]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.12.22 15:57
Оценка:
Здравствуйте, ·, Вы писали:


S>> и DTO сгенерить. Не вижу каких то проблем.

·>Как сгенерить-то?
Да легко! SG пишут не боги.
S>> Только странно как то из описания генерить сервер. Больше нужен клиент.
·>И то, и то нужно. В этом и сила, что клиент и сервер генерятся на основе одной и той же спеки, что гарантирует их совместимость. Притом разные части api можно реализовывать на разном стеке технологий в зависимости от требований.
Да не вижу особых проблем написать. Или это какой то охрененный хак что бы по json описанию сложность какая то сгенерить partial класс с partial нужными методами и параметрами.
Ну и сгенерить класс с методами внутри NotImplementedException , если такого файла нет и добавить его в проект.
Это вообще студенческая поделка!
и солнце б утром не вставало, когда бы не было меня
Re[20]: Догонит ли net java?
От: Gt_  
Дата: 14.12.22 19:56
Оценка:
Gt_>>я ничего не путаю, именно ты собрался в рукопашную писать модели, пользуясь выразительностью языка (тм)

НС>И при чем тут наследование? Наследование в том же REST — редкостный геморой.


не трогаем пока рест. у одной стороны все начинается с генератора, у тебя с модели. вот и расскажи, как ты модель дефинируешь. раз наследование геморой, всякие created_by, date_modified в ручную в каждую табличку прописываешь или что ?


Gt_>>по мне, так очень необычный подход.


НС>Ну это по тебе. А так очень распространенный подход.


ну как минимум в этой теме ты единственный такой. остальные тут явно прогнулись под моду DSL.
Отредактировано 14.12.2022 19:59 Gt_ . Предыдущая версия .
Re[33]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 15.12.22 06:54
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.

·>Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot

Опять пошли по кругу.

·>Ты сам придумал генерацию нескольких моделей по одному описанию.


4. то же описание из 2 используем для генерапции клиентов на Java/C#/JS.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[35]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 15.12.22 06:54
Оценка:
Здравствуйте, ·, Вы писали:

S>>https://learn.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-6.0&amp;tabs=visual-studio

S>>Вобще то много чего есть. Даже summary берет
·>Как я вижу, оно не умеет серверный код генерить.

Оно и не должно. Потому что код на C# — первичен, а не наоборот. Для любителей писать спеку openapi руками есть другие инструменты.

·>Вот вы и мучаетесь.


Как видишь, опять ты мимо.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[21]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 15.12.22 06:57
Оценка:
Здравствуйте, Gt_, Вы писали:

НС>>И при чем тут наследование? Наследование в том же REST — редкостный геморой.

Gt_>не трогаем пока рест.



Gt_> у одной стороны все начинается с генератора, у тебя с модели. вот и расскажи, как ты модель дефинируешь. раз наследование геморой, всякие created_by, date_modified в ручную в каждую табличку прописываешь или что ?


Code first? Не, не слышал.
Если что, я не сторонник использования code first в случае БД. Но не по причинам, озвученным здесь, а потому что куда чаще схема БД есть до написания кода. Отсутствие необходимости в свойствах в языке тут никаким боком.

Gt_>>>по мне, так очень необычный подход.

НС>>Ну это по тебе. А так очень распространенный подход.
Gt_>ну как минимум в этой теме ты единственный такой. остальные тут явно прогнулись под моду DSL.

Остальные это два человека? Отличный аргумент!
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: Догонит ли net java?
От: Gt_  
Дата: 15.12.22 08:49
Оценка:
НС>Code first? Не, не слышал.
НС>Если что, я не сторонник использования code first в случае БД. Но не по причинам, озвученным здесь, а потому что куда чаще схема БД есть до написания кода. Отсутствие необходимости в свойствах в языке тут никаким боком.

в сухом остатке ты лишь на форумах рассуждаешь "выразительности языка" (тм), а когда доходит до дела, ты вспоминаешь про орм и засовываешь эту выразительность подальше. тупо пишешь руками каждое поле каждой табличке в модели руками, повторяя одни и те же поля в каждой табличке, нарушая принципы DRY. при этом изображаешь непонимание при вопросах с чуть более сложными сценариями. ну ок, я понял.
хорошая иллюстрация откуда пошла мода на DSL.
Re[23]: Догонит ли net java?
От: Ночной Смотрящий Россия  
Дата: 15.12.22 09:00
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>в сухом остатке ты лишь на форумах рассуждаешь "выразительности языка" (тм), а когда доходит до дела, ты вспоминаешь про орм и засовываешь эту выразительность подальше. тупо пишешь руками каждое поле каждой табличке в модели руками, повторяя одни и те же поля в каждой табличке, нарушая принципы DRY.


Нет.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[34]: Догонит ли net java?
От: · Великобритания  
Дата: 15.12.22 09:38
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.

НС>·>Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot
НС>Опять пошли по кругу.
Ты сам на этот круг пошел. "разметка asp.net никуда не денется" — ошибка.

НС>·>Ты сам придумал генерацию нескольких моделей по одному описанию.

НС>

НС>4. то же описание из 2 используем для генерапции клиентов на Java/C#/JS.

Где здесь несколько моделей? API одно и то же, модель та же, просто на разных яп.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Догонит ли net java?
От: · Великобритания  
Дата: 15.12.22 09:43
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>>Вобще то много чего есть. Даже summary берет

НС>·>Как я вижу, оно не умеет серверный код генерить.
НС>Оно и не должно. Потому что код на C# — первичен, а не наоборот.
Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.

НС>Для любителей писать спеку openapi руками есть другие инструменты.

Какие?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[37]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.12.22 11:40
Оценка:
Здравствуйте, ·, Вы писали:

НС>>Оно и не должно. Потому что код на C# — первичен, а не наоборот.

·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.

Спека генерируется обычно для внешних клиентов. Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.

НС>>Для любителей писать спеку openapi руками есть другие инструменты.

·>Какие?

Предполагаю, тоже фремворки разного рода. Работают вобщем так же — развесил метаданные, либа отдает по ним манифест.

С опенапи есть большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.
Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.
Re[38]: Догонит ли net java?
От: · Великобритания  
Дата: 15.12.22 13:13
Оценка:
Здравствуйте, Pauel, Вы писали:

НС>>>Оно и не должно. Потому что код на C# — первичен, а не наоборот.

P>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.
P>Спека генерируется обычно для внешних клиентов.
Ну вот тут
Автор: varenikAA
Дата: 07.09.20
сгенерировали. И клиентам пришлось пойти лесом. Добрые вы. Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.

P>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.

Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии. Там и rest-то не особо нужен. Можно просто описывать api в виде c#-либы. Это не code-first, а code-only. Т.к. отдельные спеки не нужны в принципе.

НС>>>Для любителей писать спеку openapi руками есть другие инструменты.

P>·>Какие?
P>Предполагаю, тоже фремворки разного рода. Работают вобщем так же — развесил метаданные, либа отдает по ним манифест.
Возможно. Я не видел для шарпа.

P>С опенапи есть

Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.
В лучшем случае получается такая схема:

code1 + метаданные --[generator1]--> spec
spec --[generator2]--> code2

Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.
Ещё недостаток, что generator1 и generator2 очень разные. Т.к. первый должен уметь парсить язык метаданных и генерить и генерить язык спеки, а второй генератор должен уметь парсить язык спеки и генерить на желаемом языке программирования.

Схема должна быть проще:
spec --[generator1]--> code1
spec --[generator2]--> code2

И развешивать метаданные становится просто не нужно.
И генераторы примерно одинаковые, часто тот же софт, параметры запуска только слегка отличаются, — они оба должны одинаково парсить тот же язык спеки и отличаться только шаблонами генерации на желаемых языках программирования.

P>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.

Это не проблема, это фича.

P>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.

Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 15.12.2022 13:28 · . Предыдущая версия . Еще …
Отредактировано 15.12.2022 13:27 · . Предыдущая версия .
Отредактировано 15.12.2022 13:19 · . Предыдущая версия .
Re[39]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.12.22 13:52
Оценка:
Здравствуйте, ·, Вы писали:

P>>Спека генерируется обычно для внешних клиентов.

·>Ну вот тут
Автор: varenikAA
Дата: 07.09.20
сгенерировали. И клиентам пришлось пойти лесом. Добрые вы.


То есть, непойми какая проблема у когото, но виноваты мы? Ты адекватен?

Если это про OpenApi, то с ним большие проблемы. О чем и речь. При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками.
Для OpenAPI нужно
1. хороший фремворк клиента и сервера
2. кодогенератор, который генерирует код под конкретный фремворк
3. возможность расширения/допиливания кодогенератора
Судя по обилию кодогенераторов с разными наборами фич OpenAPI представляет собой большое развлечение.

> Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.


Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими.
И тут становится ясно, что, например, вендор сервиса, который обновился "а у нас тесты зелёные", может сломать всё, т.к. ты для него всего лишь один из сотен консумеров.
А твои юзера попадут на бабки, т.к. твоя система на проде только хелсчек делает.
Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.

Пример — сторонний вендор добавил всего лишь метаданные, которые должен был добавлять раньше, но не добавлял. Т.е. просто фиксанул бажок.
Фактически — ничего не сломал. Но благодаря этим изменениям есть огромный шанс, что часть консумеров будут криво работать т.к. их QA тестировали с пакетами записаными с прода. Гы-гы.

P>>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.

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

То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!

P>>С опенапи есть

·>Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.

До тебя не доходит — не надо ничего придумывать — берешь провереное, протестированое решение.

·>В лучшем случае получается такая схема:

·>code1 + метаданные --[generator1]--> spec
·>spec --[generator2]--> code2

В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.

·>Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.


Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.

·>Схема должна быть проще:

·>spec --[generator1]--> code1
·>spec --[generator2]--> code2

Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше.

·>И развешивать метаданные становится просто не нужно.


Ну ок — я хочу фремворк XxX-yyy-zzz. Где мне взять генератор для него? Упс!
А происходит это просто — стартовали на xxx-yyy-zzz, а в версии 5.0 понадобился OpenAPI
Приплызд!

P>>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.

·>Это не проблема, это фича.

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

P>>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.

·>Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.

С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает
1. например лицензия, GPL какой
2. архитектура генератора, где всё огорожено забором
3. сложность этого генератора, например, отсутствие тестов. Гы-гы.

То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.
Отредактировано 15.12.2022 14:30 Pauel . Предыдущая версия .
Re[40]: Догонит ли net java?
От: · Великобритания  
Дата: 15.12.22 18:45
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Спека генерируется обычно для внешних клиентов.

P>·>Ну вот тут
Автор: varenikAA
Дата: 07.09.20
сгенерировали. И клиентам пришлось пойти лесом. Добрые вы.

P>То есть, непойми какая проблема у когото, но виноваты мы? Ты адекватен?
Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками.

P>Если это про OpenApi, то с ним большие проблемы. О чем и речь.

Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь?

P>При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками.

Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии.

>> Потому у вас и проблемы с интеграцией в проде, а тех у кого таких проблем нет — считаете богами.

P>Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими.
Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы.

P>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.

Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление. А значит юзеры уже имеют проблемы, прямо сейчас, и поздно пить боржоми. Или ты что-то не договариваешь, называя продом SIT или staging, который как прод, но изолирован от пользователей.

P>Пример — сторонний вендор добавил всего лишь метаданные, которые должен был добавлять раньше, но не добавлял. Т.е. просто фиксанул бажок.

И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов. Её и надо фиксить. А не пытаться закатить тесты в прод.

P>>>Вот у нас, скажем, для внутреннего использования вообще генератор не нужен — он вносит некоторый хаос и удлинняет цикл разработки. Описание апи одновременно является и клиентом к этому апи. Все что тебе надо — подкинуть реализацию.

P>·>Я уже говорил, что такое работает только в маленьких проектах, где все свои, весь код на одном яп примерно одной версии.
P>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!
Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы...

P>·>Опенапи это частный случай. Проблема в другом, в самом подходе code-first. Люди считают свой основной любимый яп — самым лучшим и правильным. Придумать способ развешивания метаданных, чтобы потом сгенерилась спека, а дальше хоть потоп.

P>До тебя не доходит — не надо ничего придумывать — берешь провереное, протестированое решение.
Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю.

P>·>В лучшем случае получается такая схема:

P>·>code1 + метаданные --[generator1]--> spec
P>·>spec --[generator2]--> code2
P>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.
Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать?

P>·>Так вот становится очень печально, когда приходится жонглировать одновременно с code1, метаданные, generator1, generator2 чтобы получился вменяемый code2. В итоге на это дело плюют и, как по ссылке выше, начинают писать code2 вручную и generator1, spec становятся просто бесполезны. Особенно плакать хочется когда внезапно появляется spec --[generator3]--> code3 и т.д.

P>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.
Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор).

P>·>Схема должна быть проще:

P>·>spec --[generator1]--> code1
P>·>spec --[generator2]--> code2
P>Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше.
Что значит "взять"? У тебя оно уже вроде есть, но генерится.

P>·>И развешивать метаданные становится просто не нужно.

P>Ну ок — я хочу фремворк XxX-yyy-zzz. Где мне взять генератор для него? Упс!
P>А происходит это просто — стартовали на xxx-yyy-zzz, а в версии 5.0 понадобился OpenAPI
P>Приплызд!
А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например.

P>>>большая проблема — генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера, и у всех разные фичи этого openapi.

P>·>Это не проблема, это фича.
P>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет.
А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке?

P>И тут приходится писать кодогенератор самому, т.к. другого выхода нет.

Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов".

P>>>Например, тебе нужен ResponseHeaders, вот сиди и перебирай генератор/либу, которые хорошо это умеют. Нужен correlation — перечень либ/генераторов сужается. Вобщем, кунсткамера.

P>·>Генератор в принципе относительно примитивная штука, по сути набор текстовых шаблонов. Легко дорабатывается напильником.
P>С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает
С того, что это тупо шаблончик типа mustache, результат работы которого надёжно проверяется компилятором. Сделать работающее решение очень просто, именно поэтому "генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера". На порядок проще, чем придумывать и развешивать метаданные, добавлять дополнительную метаинформацию, обрабатывать всё это дело и пытаться сгенерить хоть что-то полезное из этого, именно поэтому лишь "чисто теоретически я знаю как все таки сделать нормальный генератор".

P>1. например лицензия, GPL какой

P>2. архитектура генератора, где всё огорожено забором
P>3. сложность этого генератора, например, отсутствие тестов. Гы-гы.
Ровно эти же проблемы могут быть и у твоего схемогенератора.

P>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.

Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку. Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут
Автор: varenikAA
Дата: 07.09.20
.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 15.12.2022 18:59 · . Предыдущая версия .
Re[37]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.12.22 07:34
Оценка:
Здравствуйте, ·, Вы писали:

·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.

Зачем писать для клиента руками?
https://stackoverflow.com/questions/54094688/generate-net-client-from-swagger
https://habr.com/ru/post/488102/

https://learn.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-5.0&amp;tabs=visual-studio
https://learn.microsoft.com/ru-ru/aspnet/core/tutorials/getting-started-with-nswag?view=aspnetcore-7.0&amp;tabs=visual-studio
и солнце б утром не вставало, когда бы не было меня
Отредактировано 16.12.2022 7:42 Serginio1 . Предыдущая версия . Еще …
Отредактировано 16.12.2022 7:37 Serginio1 . Предыдущая версия .
Re[38]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 08:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.

S>Зачем писать для клиента руками?
Ты за дискуссией не следишь? Это предлагает
Автор: varenikAA
Дата: 07.09.20
Ночной Смотрящий, у него и спрашивай, ему советы и давай.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[39]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.12.22 08:51
Оценка:
Здравствуйте, ·, Вы писали:

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


S>>·>Ты так и не рассказал, накой же тогда генерить из этого кода спеку, и что с ней потом делать. Т.к. клиентов ты всё равно пишешь руками.

S>>Зачем писать для клиента руками?
·>Ты за дискуссией не следишь? Это предлагает
Автор: varenikAA
Дата: 07.09.20
Ночной Смотрящий, у него и спрашивай, ему советы и давай.

Это было еще в 20 году. Сейчас уже 23 скоро. Этих генераторов сейчас как собак нерезанных.
НС кстати тогда и писал

В свое время перебрали пачку генераторов и пришли к выводу что писать клиентов нужно руками.
Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.

и солнце б утром не вставало, когда бы не было меня
Отредактировано 16.12.2022 8:55 Serginio1 . Предыдущая версия .
Re[40]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 10:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Зачем писать для клиента руками?

S>·>Ты за дискуссией не следишь? Это предлагает
Автор: varenikAA
Дата: 07.09.20
Ночной Смотрящий, у него и спрашивай, ему советы и давай.

S>Это было еще в 20 году. Сейчас уже 23 скоро. Этих генераторов сейчас как собак нерезанных.
Ёлок много и тебя много! А толку — маловато будет!

S>НС кстати тогда и писал

S>

S>В свое время перебрали пачку генераторов и пришли к выводу что писать клиентов нужно руками.
S>Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.

Угу. И космические корабли бороздят просторы вселенной.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 16.12.2022 10:03 · . Предыдущая версия .
Re[41]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.12.22 10:18
Оценка:
Здравствуйте, ·, Вы писали:

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


S>>>>Зачем писать для клиента руками?

S>>·>Ты за дискуссией не следишь? Это предлагает
Автор: varenikAA
Дата: 07.09.20
Ночной Смотрящий, у него и спрашивай, ему советы и давай.

S>>Это было еще в 20 году. Сейчас уже 23 скоро. Этих генераторов сейчас как собак нерезанных.
·>Ёлок много и тебя много! А толку — маловато будет!
То есть ты эксперт в нетовских генераторах Rest клиентов?
Или тебе Рабинович напел?
Ошибки находятся и исправляются. Без ошибок никто не пишет
и солнце б утром не вставало, когда бы не было меня
Re[41]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.12.22 10:35
Оценка:
Здравствуйте, ·, Вы писали:

·>Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками.


Сам подумай, что это значит — кодогенераторы в общей массе отстой. И именно ты топишь за использование тех, которые отстой.

P>>Если это про OpenApi, то с ним большие проблемы. О чем и речь.

·>Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь?

Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками"
Похоже, ты снова начал валять дурака и откровенно передергивать.

P>>При чем независимо от того, генерируешь ли ты манифест, или задаёшь руками.

·>Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии.

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

P>>Заявление "на проде проблем нет" сводится к неполному профессионализму. Лучше отказаться от предположений "у нас на проде проблем нету", и рассмотреть риски и способы управления ими.

·>Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы.

А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей.

P>>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.

·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление.

Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса.

·>И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов.


Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч.
Например, ты заюзал sendgrid или mailgun. Они трохи обновились. Ты же фанат емейлов и всё такое. И вот после их обновления часть ваших юзеров перестала получать уведомления. Гы-гы.
Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки!

P>>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!

·>Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы...

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

·>Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю.


Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать
Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд

P>>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.

·>Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать?

Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам.

P>>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.

·>Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор).

Теоретик?
1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы.
2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто.
3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер.

P>>·>Схема должна быть проще:

P>>·>spec --[generator1]--> code1
P>>·>spec --[generator2]--> code2
P>>Если под spec взять OpenAPI, то получим геморрой, который ты сам же описал выше.
·>Что значит "взять"? У тебя оно уже вроде есть, но генерится.

"Взять" — подставляем вместо spec в твоей форумуле успеха OpenAPI, и проверяем твою гипотезу
И оказывается, что именно здесь получается бред, который ты сам же и описал.

P>>Приплызд!

·>А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например.

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

P>>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет.

·>А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке?

Генерится не из произвольно написаного кода, а из метаданных которые предоставляются либой. Они по своей природе навешиваются на что угодно без проблем.

P>>И тут приходится писать кодогенератор самому, т.к. другого выхода нет.

·>Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов".

Он пишет про другое — ты внимательно прочитай.

P>>С чего ты взял, что доработаешь? Фантазии? Использовать или доработать напильником мешает

·>С того, что это тупо шаблончик типа mustache, результат работы которого надёжно проверяется компилятором.

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

> Сделать работающее решение очень просто, именно поэтому "генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера".


Наоборот — генераторы приходится писать, потому что они в основной массе ни на что не годятся. Берешь генератор кода, и вдруг оказывается, что в генеренном коде нужен хук для инструментирования.
А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии.

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


Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности.

P>>1. например лицензия, GPL какой

P>>2. архитектура генератора, где всё огорожено забором
P>>3. сложность этого генератора, например, отсутствие тестов. Гы-гы.
·>Ровно эти же проблемы могут быть и у твоего схемогенератора.

Нисколько. Схемогенератор это простая вещь по сравнению с кодогенератором.

P>>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.

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

Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода.

> Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут
Автор: varenikAA
Дата: 07.09.20
.


Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя.
Re[42]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 10:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>·>Ёлок много и тебя много! А толку — маловато будет!

S>То есть ты эксперт в нетовских генераторах Rest клиентов?
S> Или тебе Рабинович напел?
S>Ошибки находятся и исправляются. Без ошибок никто не пишет
Ты правда за дискуссией не следишь. Мой тезис в том, что тут ошибка в подходе, а не в конкретных багах. "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов." — тупиковый путь. Перечитай мои сообщения, там будут обоснования, не хочу повторяться.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[42]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 11:27
Оценка:
Здравствуйте, Pauel, Вы писали:

P>·>Это видимо только ты не понял у кого проблемы. Проблема у Ночного Смотрящего, с которым я тут непосредственно беседую. Именно он перебрал кучу кодогенераторов, плюнул и предложил писать всё ручками.

P>Сам подумай, что это значит — кодогенераторы в общей массе отстой. И именно ты топишь за использование тех, которые отстой.
Спорить не буду, ибо не важно это. Мой тезис, что схемогенераторы — ещё более отстой, чем кодогенераторы.

P>>>Если это про OpenApi, то с ним большие проблемы. О чем и речь.

P>·>Т.е. твой вариант — не использовать никакой openapi и весь код писать руками, как деды завещали и Ночной Смотрящий делает. Так? Или какую альтернативу ты предлагаешь?
P>Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками"
Угу. Так используй проверенную оттестированную либу для кодогенерации. Кто запрещает-то?

P>·>Очень даже зависимо. Вручную сделанный openapi проще поддерживать во вменяемом состоянии.

P>Как мы выяснили, у OpenAPI проблема не с манифестом, а с кодогенерацией.
P>Поскольку кодогенераторы для OpenAPI кривые, шо сабля, то тебе надо точно знать фичи кодогенератора, и избегать лишнего в манифесте
P>В противном случае лишняя строчка в манифесте или сломает клиент, или сломает сервер, или просто проигнорится
P>И то, и другое, и третье есть проблема
И чем поможет схемогенератор?

P>·>Ты как-то упустил слово _таких_. Этот подход решает вполне определённый класс проблем. Но, ясен пень, не решает все проблемы.

P>А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей.
Нет, не следует.

P>>>Соответственно если у тебя есть тесты прода — пусканул после обновления их сервиса, выявил проблемы, и до того, как юзеры проснулись, уже всё пофиксано.

P>·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление.
P> Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса.
Это и лечится SIT.

P>·>И выкатил в прод без тестов интеграции с вами? Так тут проблема в том, что кто-то что-то выкатывает в прод без тестов.

P>Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч.
Про conformance tests я уже тоже рассказывал.

P>Например, ты заюзал sendgrid или mailgun. Они трохи обновились. Ты же фанат емейлов и всё такое. И вот после их обновления часть ваших юзеров перестала получать уведомления. Гы-гы.

P>Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки!
Нормальные вендоры предоставляют средства для тестирования. Ищем для первого упомянутого: https://docs.sendgrid.com/ui/sending-email/email-testing
Те вендоры, которые не могут это обеспечить либо посылаются лесом, либо, если совсем выбора нет, монополисты, требуют очень пристального внимания.

P>>>То есть, вы не смогли промигрировать код на нужную версию яп — всё, большой проект, оло-ло-ло-ло!

P>·>Что значит "не смогли"? Тут всё просто. Бюджета нет, проект в состоянии EoL, команду разогнали — никто мигрировать не будет. Ты в большой организации никогда не работал? +100к работников чтобы...
P>Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву.
И что?

P>·>Совершенно верно, и не поспоришь — лучше быть здоровым и богатым, чем больным и бедным. Ну так бери проверенное протестированное решение и в contract-first с openapi, я разрешаю.

P>Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать
И? В чём твой солюшн-то?

P>Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд

Я сам их подпатчивал и даже пулл-реквесты засылал, мелочёвку правда, и их даже мержили, не рокет-сайнс совершенно.

P>>>В лучшем случае, я уже сказал, генератор не нужен. Он необходим только для экспорта АПИ.

P>·>Продолжай. Что за экспорт АПИ? И что с результатом экспорта потом делать?
P>Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам.
Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?

P>>>Ты описал типичную картину для OpenAPI, независимо от того, генеришь манифест, или пишешь руками.

P>·>Очень даже зависимо. Т.к. цепочка жонглирования становится короче и количество сущностей уменьшается (не нужно писать метаданные, не нужен их парсер и схемогенератор).
P> Теоретик?
P>1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы.
То же и со схемогенератором. Или он у тебя универсальный всемогутер?

P>2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто.

А надо-то генерировать не что угодно, а только то, что умеет openapi.

P>3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер.

У тебя не просто схемогенератор, а схемогенератор+кодогенератор. Иначе генерить схему без последующей кодогенерации — зря электричество жечь.
Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.

P>·>Что значит "взять"? У тебя оно уже вроде есть, но генерится.

P>"Взять" — подставляем вместо spec в твоей форумуле успеха OpenAPI, и проверяем твою гипотезу
P>И оказывается, что именно здесь получается бред, который ты сам же и описал.
Так у тебя бреда получается ещё больше.

P>>>Приплызд!

P>·>А абсолютно всемогущий безбажный генератор спеки из развешанных метаданных вам бог ниспосылает. Счастливчики, не всем так везёт, вот Ночному Смотрящему и тем погромистам из restapi.moedelo.org не повезло, например.
P>С генератором спеки гораздо проще. Кодогенератор это намного более сложная задача.
P>Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным.
Спекогенератор без кодогенератора не нужен. Так что задачу создания кодогенератора решать всё равно придётся. Единственно, чем ты можешь парировать, это тем, что решение задачи кодогенератора ты можешь спихнуть на других и всё ещё получить свою зарплату за "успешно" сданный проект.

P>>>Это проблема — пока найдешь нужную комбинацию, вспотеешь. А если у тебя уже готовый проект, то втиснуть него нечто иное не факт, что выйдет.

P>·>А сгенерить нечто полезное почему выйдет из произвольно написанного готового проекта на произвольном фреймворке?
P>Генерится не из произвольно написаного кода, а из метаданных которые предоставляются либой. Они по своей природе навешиваются на что угодно без проблем.
Я знаю. Только это всё усложняет.

P>>>И тут приходится писать кодогенератор самому, т.к. другого выхода нет.

P>·>Так же придётся писать спекогенератор, что Ночной Смотрящий рассуждал 2 года назад: "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов".
P>Он пишет про другое — ты внимательно прочитай.
Я прочитал и понял именно так. Если у тебя есть другая интерпретация, выкладывай.

P> компилер говорит тебе, что выхлоп компилируется. А что выхлоп нерабочий или содержит не то, или не содержит того, никакой компилер тебе не подскажет.

>> Сделать работающее решение очень просто, именно поэтому "генераторов кода для него вагон и маленькая тележка, все поддерживают разные архитектуры клиента-сервера".
P>Наоборот — генераторы приходится писать, потому что они в основной массе ни на что не годятся. Берешь генератор кода, и вдруг оказывается, что в генеренном коде нужен хук для инструментирования.
P>А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии.
Ну зашли пулл-реквест.
Впрочем, мне не доводилось видеть такого, обычно такие генераторы предоставляют возможность конфигурации кастомнымными шаблонами.

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

P>Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности.
Это не я их предлагаю придумывать, а Ночной Смотрящий, ему это и советуй.

P>>>То есть, твоя "доработка" по сложности даст примерно то же, что генерация JSON по метаданным. Примерно та же сложность сопровождения, примерно то же количество тестов.

P>·>Это неправда. Более того, тебе придётся такой генератор писать в любом случае, если ты хочешь хоть как-то использовать спеку.
P>Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода.
Тесты можно писать проще, без схемы и специальных тулов.

>> Единственное как можно "решить" эту проблему, это сваять какую-нибудь хрень, вывалить сгенерённую спеку клиентам и сказать, что это их проблема что они потом будут с ней делать. Это именно то, что сделали погромисты тут
Автор: varenikAA
Дата: 07.09.20
.

P>Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя.
Ты читать точно умеешь? https://restapi.moedelo.org/docs — это именно что сгенерённая swagger схема. Которую невозможно ни для чего полезного применить, даже глазками почитать и то проблема, тулзы на ней затыкаются.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[43]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.12.22 11:40
Оценка:
Здравствуйте, ·, Вы писали:

·>Ты правда за дискуссией не следишь. Мой тезис в том, что тут ошибка в подходе, а не в конкретных багах. "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов." — тупиковый путь. Перечитай мои сообщения, там будут обоснования, не хочу повторяться.

Это было 2 года назад. Есть различные резолверы итд. Все развивается. Тут уже вопросы о полноте описания классов и методов в swagger.
Например по сравнению с wsdl. Проблем с wsdl не было.
и солнце б утром не вставало, когда бы не было меня
Re[44]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 11:51
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>·>Ты правда за дискуссией не следишь. Мой тезис в том, что тут ошибка в подходе, а не в конкретных багах. "большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов." — тупиковый путь. Перечитай мои сообщения, там будут обоснования, не хочу повторяться.

S> Это было 2 года назад. Есть различные резолверы итд. Все развивается. Тут уже вопросы о полноте описания классов и методов в swagger.
Именно мы эти вопросы и обсуждаем. Вместо того, чтобы просто полно описывать классы и методы напрямую в swagger, приходится "всё развивать" (с нулевым успехом по факту) дополнительную метаинформацию и допиливать и так уже нетривиальный swashbuckle.

S>Например по сравнению с wsdl. Проблем с wsdl не было.

Верно. И поэтому он благополучно скончался.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[45]: Догонит ли net java?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.12.22 12:00
Оценка:
Здравствуйте, ·, Вы писали:

S>>Например по сравнению с wsdl. Проблем с wsdl не было.

·>Верно. И поэтому он благополучно скончался.
Это все проблемы с браузерами, а именно JS. На него и было изначально недоделанный swagger настроен со своим недоделанным json.
yaml хоть ввести додумались!
и солнце б утром не вставало, когда бы не было меня
Re[43]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.12.22 12:43
Оценка:
Здравствуйте, ·, Вы писали:

P>>Сам подумай, что это значит — кодогенераторы в общей массе отстой. И именно ты топишь за использование тех, которые отстой.

·>Спорить не буду, ибо не важно это. Мой тезис, что схемогенераторы — ещё более отстой, чем кодогенераторы.

У тебя нет аргументов.

P>>Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками"

·>Угу. Так используй проверенную оттестированную либу для кодогенерации. Кто запрещает-то?

Отсутствие таких в природе с силу принципиальной сложности кодогенерации.

P>>В противном случае лишняя строчка в манифесте или сломает клиент, или сломает сервер, или просто проигнорится

P>>И то, и другое, и третье есть проблема
·>И чем поможет схемогенератор?

Генератор схемы это не какая нибудь сложная вещь, легко покрывается тестами, в отличие от кодогенератора.
Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.

P>>А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей.

·>Нет, не следует.

У тебя снова нет аргументов, поздравляю!

P>>·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление.

P>> Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса.
·>Это и лечится SIT.

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

P>>Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч.

·>Про conformance tests я уже тоже рассказывал.

Ты же не собираешься запускать их на проде. А значит будешь тестировать "юзером".
У них тесты зеленые. А твоя система против их новой версии никогда не работала.
Приплызд.

P>>Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки!

·>Нормальные вендоры предоставляют средства для тестирования. Ищем для первого упомянутого: https://docs.sendgrid.com/ui/sending-email/email-testing

Именно такие тесты и нужно пускануть после обновления с их стороны. Альтернатива — "у нас багов нет", это твой любимый вариант.

P>>Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву.

·>И что?

Ты говоришь про большой проект, а под признаки подходит любой, где нет денег. Например — 1 человек работает вместо команды и кое как справляется, на миграцию денег-времени нет.
То есть, ты просто накидываешь абы что.

P>>Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать

·>И? В чём твой солюшн-то?

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

P>>Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд

·>Я сам их подпатчивал и даже пулл-реквесты засылал, мелочёвку правда, и их даже мержили, не рокет-сайнс совершенно.

Именно что мелочевку. А что делать с большими фичами-багами — не ясно.
Обилие кривых кодогенераторов гарантирует затраты времени на выбор подходящего.

P>>Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам.

·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?

Что им надо делать, то и будут.

P>> Теоретик?

P>>1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы.
·>То же и со схемогенератором. Или он у тебя универсальный всемогутер?

Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.

P>>2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто.

·>А надо-то генерировать не что угодно, а только то, что умеет openapi.

В слова решил поиграть?

P>>3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер.

·>У тебя не просто схемогенератор, а схемогенератор+кодогенератор. Иначе генерить схему без последующей кодогенерации — зря электричество жечь.

Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.

·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.


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

>>И оказывается, что именно здесь получается бред, который ты сам же и описал.

·>Так у тебя бреда получается ещё больше.

Главное что ты сам себе противоречишь.

P>>Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным.

·>Спекогенератор без кодогенератора не нужен.

Ты так и не сказал, зачем кодогенератор есть уже есть генератор спеки.

P>>Генерится не из произвольно написаного кода, а из метаданных которые предоставляются либой. Они по своей природе навешиваются на что угодно без проблем.

·>Я знаю. Только это всё усложняет.

А я вижу, что облегчают.

P>>Он пишет про другое — ты внимательно прочитай.

·>Я прочитал и понял именно так. Если у тебя есть другая интерпретация, выкладывай.

Он пишет о том, что хороших кодогенератов для клиента не нашли.

P>>А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии.

·>Ну зашли пулл-реквест.

И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.

P>>Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности.

·>Это не я их предлагаю придумывать, а Ночной Смотрящий, ему это и советуй.

Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.

P>>Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода.

·>Тесты можно писать проще, без схемы и специальных тулов.

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

P>>Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя.

·>Ты читать точно умеешь? https://restapi.moedelo.org/docs — это именно что сгенерённая swagger схема. Которую невозможно ни для чего полезного применить, даже глазками почитать и то проблема, тулзы на ней затыкаются.
1. есть схема
2. какие то кодогенераторы с ней не справляются
С чего ты взял, что она генерированая? Подробнее. Я видел и бОльшие простыни, созданные вручную.
Отредактировано 16.12.2022 13:05 Pauel . Предыдущая версия . Еще …
Отредактировано 16.12.2022 12:53 Pauel . Предыдущая версия .
Re[44]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 14:26
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Очевидно, что не так. Я пишу — использовать проверенную оттестированую либу, но тебе мерещится "писать весь код руками"

P>·>Угу. Так используй проверенную оттестированную либу для кодогенерации. Кто запрещает-то?
P>Отсутствие таких в природе с силу принципиальной сложности кодогенерации.
Я ими пользовался. Работает хорошо, если схема вменяемая.

P>·>И чем поможет схемогенератор?

P>Генератор схемы это не какая нибудь сложная вещь, легко покрывается тестами, в отличие от кодогенератора.
P>Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.
Вообще элементарно. Результат кодогенерации очень надёжно тестируется компилятором.

P>>>А раз не решает все, то часть останутся на проде. Гы-гы. Откуда и следует, что нужно тестировать и прод. Например — при обновлении 3rd party зависимостей.

P>·>Нет, не следует.
P>У тебя снова нет аргументов, поздравляю!
Ну не следует и всё тут. Достаточно тестировать тестовое окружение.

P>>>·>Чтобы пускануть тесты в проде и выявить эту проблему, в этом самом проде уже должно оказаться их обновление.

P>>> Алё — они поменяли свой сервис глядя в свои тесты. И подломали некоторые запросы твоего сервиса.
P>·>Это и лечится SIT.
P>Не лечится. Напомню — у вендора таких как ты 100500 контрактов. Тестировать как их новое апи ведет себя с каждым из консумером они никак не могут.
P>Максимум, для особых кейсов могут предоставить тестовые инстансы.
Этого достаточно.

P>Но это не гарантирует решение всех проблем.

А что гарантирует решение всех проблем?

P>>>Это норма, а не проблема. Крупные вендоры апи имеют десятки и сотни тысяч консумеров. Ты для них один из сотен тысяч.

P>·>Про conformance tests я уже тоже рассказывал.
P>Ты же не собираешься запускать их на проде. А значит будешь тестировать "юзером".
тестовым юзером.

P>>>Пускаешь тесты прода и видишь, что емейлы таки глючат. Опаньки!

P>·>Нормальные вендоры предоставляют средства для тестирования. Ищем для первого упомянутого: https://docs.sendgrid.com/ui/sending-email/email-testing
P>Именно такие тесты и нужно пускануть после обновления с их стороны. Альтернатива — "у нас багов нет", это твой любимый вариант.
Только это не прод, а тест.

P>>>Тогда это не признак большого проекта, а скорее признак тухлого проекта, который еле держится на плаву.

P>·>И что?
P>Ты говоришь про большой проект, а под признаки подходит любой, где нет денег. Например — 1 человек работает вместо команды и кое как справляется, на миграцию денег-времени нет.
Вот только что свежачок
Автор: Ночной Смотрящий
Дата: 16.12.22
от Ночного Смотрящего: "уже год пытаемся с 3.1 слезть, но пока только отдельные сервисы переползли". Вот и расскажи ему какой у него тухляк и денег у них нет и научи его жизни.

P>То есть, ты просто накидываешь абы что.

Это не накидывание, а реальность.

P>>>Мы уже выяснили — бредогенераторов для openapi 100500 единиц, и почти все из них или не подходят, или их нельзя использовать

P>·>И? В чём твой солюшн-то?
P>Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей.
Ты расскажи. Зачем схема внешним консьюмерам?

P>Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент.

Не распарсил. Что автоматически?

P>>>Типичный кейс — понадобилась некоторая фича, а кодогенератор не поддерживает, приплызд

P>·>Я сам их подпатчивал и даже пулл-реквесты засылал, мелочёвку правда, и их даже мержили, не рокет-сайнс совершенно.
P>Именно что мелочевку. А что делать с большими фичами-багами — не ясно.
P>Обилие кривых кодогенераторов гарантирует затраты времени на выбор подходящего.
Брад какой — "слишком много выбора, значит плохо". Ну не выбирай, напиши свой. Это вполне под силу даже миддлу.

P>>>Экспорт АПИ — это ты предоставляешь АПИ своего сервиса внешним консумерам.

P>·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?
P>Что им надо делать, то и будут.
Ясно. Проблемы консьюмеров шерифа не волнуют. ЧТД.

P>>>1 Тебе надо держать в уме возможности кодогенератора. Заюзал ты ResponseHeaders, а у тебя такое не поддерживается. Гы-гы.

P>·>То же и со схемогенератором. Или он у тебя универсальный всемогутер?
P>Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.
Гораздо проще. Валидировать сгенерённый код можно компилятором. Валидировать генерённый json и по каким критериям — не знаю как.

P>>>2 Метаданные парсить не нужно, это типизированый интерфейс, по которому генерить что угодно легко и просто.

P>·>А надо-то генерировать не что угодно, а только то, что умеет openapi.
P>В слова решил поиграть?
Нет. Пытаюсь достучаться. Ты должен писать такие метаданные и такой интерфейс, который хорошо ложится в openapi. Иначе то что нагенерится будет коту под хвост.

P>>>3 Вместо схемогенератора у тебя кодогенератор, при чем — два штуки, каждый со своими особенностями, клиент и сервер.

P>·>У тебя не просто схемогенератор, а схемогенератор+кодогенератор. Иначе генерить схему без последующей кодогенерации — зря электричество жечь.
P>Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.
Ты так и не рассказал зачем нужная эта схема.

P>·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.

P>Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi.
Зачем? Чтобы что?

P>Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования.

Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.

P>>>Я например писал и то, и другое. Кодогенератор это хтонический ужос по сравнению с генерацией джсон по метаданным.

P>·>Спекогенератор без кодогенератора не нужен.
P>Ты так и не сказал, зачем кодогенератор есть уже есть генератор спеки.
Сказал уже много раз. Ты просто не читаешь. Чтобы сгенерированную спеку можно было использовать с пользой.

P>>>Он пишет про другое — ты внимательно прочитай.

P>·>Я прочитал и понял именно так. Если у тебя есть другая интерпретация, выкладывай.
P>Ну так дай ссылку дай на сообщение, где НС это утверждает. Насколько я понимаю, ты искусно вырезал часть его утверждения.
Вот
Автор: varenikAA
Дата: 07.09.20
полная цитата:

Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.

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

P>>>А его нет. Гы-гы. Надо писать новый генератор, потому что допилить напильником не выходит из за GPL лицензии.

P>·>Ну зашли пулл-реквест.
P>И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.
Имя софта в студию. Или ты теоретег?

P>>>Еще раз — не надо придумывать метаданные. Алё, ты вообще читаешь? Берем проверенную либу, закладываемся на её возможности.

P>·>Это не я их предлагаю придумывать, а Ночной Смотрящий, ему это и советуй.
P>Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.
Его цитаты: "пришли к выводу что писать клиентов нужно руками". "добавления в swagger.json дополнительной метаинформации".

P>>>Снова теоретизирования Нам нужно проверить, что схема валидная. Мы берем готовый тул, который умеет слать запросы по такой спеке, и пишем под него тесты. Здесь у нас ровно 0 генеренного кода.

P>·>Тесты можно писать проще, без схемы и специальных тулов.
P> Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом.
Зачем? Если эту спецификацию ни для чего более использовать не выходит?

P>В противном случае получится так, что тесты зеленые, потому что девелоперы-тестеры намастырили их по записям со стейджа, а у клиента ничо не работает, т.к. он шлет в строгом соответствии со спекой.

Хорошо, но уже лучше. Осталось тебе понять, что не обязательно для этого генерить спеку.

P>>>Ты высек сам себя — по твоей ссылке пример работы бредо кодогенератора. Этот бредогенератор такое нагенерил, что ни руками вычистить, ни внятно использовать нельзя.

P>·>Ты читать точно умеешь? https://restapi.moedelo.org/docs — это именно что сгенерённая swagger схема. Которую невозможно ни для чего полезного применить, даже глазками почитать и то проблема, тулзы на ней затыкаются.
P>1. есть схема
P>2. какие то кодогенераторы с ней не справляются
Да мало кто справился. В этом и дело. Сделано на от*бись.

P>С чего ты взял, что она генерированая? Подробнее. Я видел и бОльшие простыни, созданные вручную.

У тебя есть сомнения?! Подскажи мне вещества, которые позволят человеку написать "Moedelo.DocumentsRegister.Api.Models.Dto.ApiDataResponseDto`1[[System.Collections.Generic.List`1[[Moedelo.DocumentsRegister.Api.Models.Dto.DocumentRegisterDto, Moedelo.DocumentsRegister.Api, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]" в однострочный полутрамеговый json.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[45]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.12.22 15:20
Оценка:
Здравствуйте, ·, Вы писали:

P>>Отсутствие таких в природе с силу принципиальной сложности кодогенерации.

·>Я ими пользовался. Работает хорошо, если схема вменяемая.

Теоретически — найти можно. Но так далеко не на любой платформе и яп.

P>>Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.

·>Вообще элементарно. Результат кодогенерации очень надёжно тестируется компилятором.

Детский сад. Как компилятор поможет, если генератор "забыл" кое какие методы сгенерировать? Компилится, значит круто?
Вообще то нет — нужны тесты.

P>>·>Нет, не следует.

P>>У тебя снова нет аргументов, поздравляю!
·>Ну не следует и всё тут. Достаточно тестировать тестовое окружение.

Недостаточно. В проде состояние системы будет другим. Data complexity никто не отменял. Если, теоретически, ты можешь 1 в 1 создать копию окружения, до единого бита, то полную копию данных точно не выйдет создать.
Но вот по факту такого не бывает, разве что для небольших приложений.

P>>Максимум, для особых кейсов могут предоставить тестовые инстансы.

·>Этого достаточно.

У тебя снова нет аргументов.

P>>Но это не гарантирует решение всех проблем.

·>А что гарантирует решение всех проблем?

Тесты на целевой системе, то есть, проде.

P>>Ты же не собираешься запускать их на проде. А значит будешь тестировать "юзером".

·>тестовым юзером.

Если на проде не тестируешь, то всегда огромный шанс, что багу первым найдет юзер, напорется, по разными причинам, например — никогда не бывает 100% соответствия стейджинга и прода.

·>Вот только что свежачок
Автор: Ночной Смотрящий
Дата: 16.12.22
от Ночного Смотрящего: "уже год пытаемся с 3.1 слезть, но пока только отдельные сервисы переползли". Вот и расскажи ему какой у него тухляк и денег у них нет и научи его жизни.


Само по себе три компилера-платформы на проекте может быть и на малом проекте, и на большом.

P>>Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей.

·>Ты расскажи. Зачем схема внешним консьюмерам?

Они это апи покупают, делают вызовы.

P>>Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент.

·>Не распарсил. Что автоматически?

Очень просто — описываешь интерфейс, обычный, либа сама делает из него клиент. Для внутреннего использования кодогенерация исключается.

P>>Обилие кривых кодогенераторов гарантирует затраты времени на выбор подходящего.

·>Брад какой — "слишком много выбора, значит плохо". Ну не выбирай, напиши свой. Это вполне под силу даже миддлу.

Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.

P>>·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?

P>>Что им надо делать, то и будут.
·>Ясно. Проблемы консьюмеров шерифа не волнуют. ЧТД.

Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.

P>>Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.

·>Гораздо проще. Валидировать сгенерённый код можно компилятором. Валидировать генерённый json и по каким критериям — не знаю как.

Детский сад — как компилер проверит, что есть два метода, которых быть не должно ? Или что нет двух методов, которые быть должны. Код то компилится!

·>Нет. Пытаюсь достучаться. Ты должен писать такие метаданные и такой интерфейс, который хорошо ложится в openapi. Иначе то что нагенерится будет коту под хвост.


Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.

P>>Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.

·>Ты так и не рассказал зачем нужная эта схема.

По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.

P>>·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.

P>>Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi.
·>Зачем? Чтобы что?

Что бы убедиться, что апи работает согласно требованиям.

P>>Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования.

·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.

Попробовали, получили отстой. Дальше что?

P>>Ты так и не сказал, зачем кодогенератор есть уже есть генератор спеки.

·>Сказал уже много раз. Ты просто не читаешь. Чтобы сгенерированную спеку можно было использовать с пользой.

Точнее — ни разу.

P>>Ну так дай ссылку дай на сообщение, где НС это утверждает. Насколько я понимаю, ты искусно вырезал часть его утверждения.

·>Вот
Автор: varenikAA
Дата: 07.09.20
полная цитата:

·>

Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.

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

То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике
Как ты этот вопрос обойдешь ручным набиванием схемы?

P>>И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.

·>Имя софта в студию. Или ты теоретег?

Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.

P>>Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.

·>Его цитаты: "пришли к выводу что писать клиентов нужно руками". "добавления в swagger.json дополнительной метаинформации".

Именно. Раз кодогенератор не умеет в семантику, а он не умеет, т.к. в манифесте такой фичи нет, то остаётся один вариант — писать руками.

P>> Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом.

·>Зачем? Если эту спецификацию ни для чего более использовать не выходит?

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

P>>1. есть схема

P>>2. какие то кодогенераторы с ней не справляются
·>Да мало кто справился. В этом и дело. Сделано на от*бись.

Вот это и есть главная причина.

P>>С чего ты взял, что она генерированая? Подробнее. Я видел и бОльшие простыни, созданные вручную.

·>У тебя есть сомнения?! Подскажи мне вещества, которые позволят человеку написать "Moedelo.DocumentsRegister.Api.Models.Dto.ApiDataResponseDto`1[[System.Collections.Generic.List`1[[Moedelo.DocumentsRegister.Api.Models.Dto.DocumentRegisterDto, Moedelo.DocumentsRegister.Api, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]" в однострочный полутрамеговый json.

Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали
Re[46]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 16:59
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.

P>·>Вообще элементарно. Результат кодогенерации очень надёжно тестируется компилятором.
P>Детский сад. Как компилятор поможет, если генератор "забыл" кое какие методы сгенерировать? Компилится, значит круто?
P>Вообще то нет — нужны тесты.
Это всё донельзя элементарно. Например, если тебе нужно сгенерировать interface MyApi {void m1(); void m2();} Кладёшь рядом файлик class ExpectedApiImpl implements MyApi{@Override m1(); @Override m2();} и получаешь ошибки компиляции если генератор что-то "забудет".
В некоторых случаях бывает и полный end-to-end тест — генератор генерит готовый демо-проект с системой билда и тестами. Так что проверить результат генерации — сбилдить свежесгенерённый проект с прогоном всех тестов.

P>·>А что гарантирует решение всех проблем?

P>Тесты на целевой системе, то есть, проде.
Тесты гарантируют решение всех проблем. Я так и знал. Спасибо. Вопросов больше нет.

P>·>тестовым юзером.

P>Если на проде не тестируешь, то всегда огромный шанс, что багу первым найдет юзер, напорется, по разными причинам, например — никогда не бывает 100% соответствия стейджинга и прода.
Ну не делайте так.

P>>>Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей.

P>·>Ты расскажи. Зачем схема внешним консьюмерам?
P>Они это апи покупают, делают вызовы.
Зачем им именно _схема_? Сгенерите им javadoc|аналог по вашему коду и вперде.

P>>>Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент.

P>·>Не распарсил. Что автоматически?
P>Очень просто — описываешь интерфейс, обычный, либа сама делает из него клиент. Для внутреннего использования кодогенерация исключается.
Это пожалуйста. Правда типично это закончится тем, что интерфейс для внутреннего использования будет немного другим, чем то что можно отдавать наружу и будете стараться усидеть на двух стульях.

P>Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.

Это не сложнее схемогенератора. И явно проще, чем схемогенератор+кодогенератор.

P>>>·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?

P>>>Что им надо делать, то и будут.
P>·>Ясно. Проблемы консьюмеров шерифа не волнуют. ЧТД.
P>Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.
Что они будут делать со схемой, которая даже с трудом парсится?

P>>>Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.

P>·>Гораздо проще. Валидировать сгенерённый код можно компилятором. Валидировать генерённый json и по каким критериям — не знаю как.
P>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?
Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.

P> Или что нет двух методов, которые быть должны. Код то компилится!

Можно даже банально набрать код в IDE, который хочешь чтобы сгенерировался, коммитишь как образец и пишешь тест посимвольного сравнения.

P>·>Нет. Пытаюсь достучаться. Ты должен писать такие метаданные и такой интерфейс, который хорошо ложится в openapi. Иначе то что нагенерится будет коту под хвост.

P>Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.
Для этого есть тесты апи, которые работают не через openapi тул.

P>>>Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.

P>·>Ты так и не рассказал зачем нужная эта схема.
P>По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.
Что значит "нужна"? Как именно они её будут использовать? Чтобы вызывать твой сервис можно использовать банальный curl.

P>>>·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.

P>>>Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi.
P>·>Зачем? Чтобы что?
P>Что бы убедиться, что апи работает согласно требованиям.
Требования _задаются_ в FRD. Сгенерённая по коду схема может лишь показать, что works as coded, про требования оно ничего сказать не может в принципе. Ах да, я забыл, у вас же тесты гарантируют решение всех проблем.

P>>>Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования.

P>·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.
P>Попробовали, получили отстой. Дальше что?
Т.е. вы поняли что у клиентов тоже будет получаться отстой. И норм. Гы.

P>>>Ну так дай ссылку дай на сообщение, где НС это утверждает. Насколько я понимаю, ты искусно вырезал часть его утверждения.

P>·>Вот
Автор: varenikAA
Дата: 07.09.20
полная цитата:

P>·>

Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.

P>·>Т.е. чтобы сгенерённую спеку можно было использовать клиентам, требуется дополнительная метаинформация и допиливание схемогенератора. И это всё теоретически.
P>То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике
Она отсутсвует потому что swashbuckle её не умеет добавлять.

P>Как ты этот вопрос обойдешь ручным набиванием схемы?

Просто впишешь семантическую метадату в схему.

P>>>И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.

P>·>Имя софта в студию. Или ты теоретег?
P>Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.
И? Имя-то будет?

P>>>Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.

P>·>Его цитаты: "пришли к выводу что писать клиентов нужно руками". "добавления в swagger.json дополнительной метаинформации".
P>Именно. Раз кодогенератор не умеет в семантику, а он не умеет, т.к. в манифесте такой фичи нет, то остаётся один вариант — писать руками.
Почему в манифесте нет-то? Потому что swashbuckle недопилен.

P>>> Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом.

P>·>Зачем? Если эту спецификацию ни для чего более использовать не выходит?
P>Эта спека нужна для того, что бы люди могли твой сервис использовать.
Конкретно рассказывай. Нужна для чего? Чтобы просто сервис использовать можно сделать тупо curl.

P>Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали

Сам-то веришь?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[47]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.12.22 19:58
Оценка:
Здравствуйте, ·, Вы писали:

P>>Вообще то нет — нужны тесты.

·>Это всё донельзя элементарно. Например, если тебе нужно сгенерировать interface MyApi {void m1(); void m2();} Кладёшь рядом файлик class ExpectedApiImpl implements MyApi{@Override m1(); @Override m2();} и получаешь ошибки компиляции если генератор что-то "забудет".

Детский лепет. Кто будет этот класс генерить? Тот же генератор или еще один генератор? То есть, как понять, может тут должен быть метод m0 или m3
Или, наоборот, одно из 1 или 2 быть не должно.

P>>Тесты на целевой системе, то есть, проде.

·>Тесты гарантируют решение всех проблем. Я так и знал. Спасибо. Вопросов больше нет.

Я слегка преувеличил, но сути это не меняет — система в эксплуатации точно так же нуждается в тестировании, мониторинге, итд.
Например, чем выше цена ошибки, тем чаще надо тестировать именно прод.

P>>Если на проде не тестируешь, то всегда огромный шанс, что багу первым найдет юзер, напорется, по разными причинам, например — никогда не бывает 100% соответствия стейджинга и прода.

·>Ну не делайте так.

Смешно. Это принципиально невозможно — на проде другой стейт, другой нетворк, другие зависимости, другая нагрузка.

P>>Они это апи покупают, делают вызовы.

·>Зачем им именно _схема_? Сгенерите им javadoc|аналог по вашему коду и вперде.

Они сами просят.

P>>Очень просто — описываешь интерфейс, обычный, либа сама делает из него клиент. Для внутреннего использования кодогенерация исключается.

·>Это пожалуйста. Правда типично это закончится тем, что интерфейс для внутреннего использования будет немного другим, чем то что можно отдавать наружу и будете стараться усидеть на двух стульях.

Напишешь другой — будет другой. А если он один, то он всего один. Он не может быть "немного другим"

P>>Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.

·>Это не сложнее схемогенератора. И явно проще, чем схемогенератор+кодогенератор.

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

    @Api('v2/api')
    @Use(Correlation, Hooks)
    class Api {
       @Get()
       @ResponseHeaders()
       method(@IsValid(idSchema) @Query('id') id:string, @RequestId() requestId?:string):Result<Entity>;
    }
...
test('should expose metadata', () => {

    expect(metadataFrom(Api)).to.deep.eq({ ... });
    expect(openapiFrom(Api)).to.deep.eq({ ... });
});


P>>Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.

·>Что они будут делать со схемой, которая даже с трудом парсится?

Наша нормально парсится.

P>>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?

·>Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.

Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.

P>> Или что нет двух методов, которые быть должны. Код то компилится!

·>Можно даже банально набрать код в IDE, который хочешь чтобы сгенерировался, коммитишь как образец и пишешь тест посимвольного сравнения.

Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.

P>>Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.

·>Для этого есть тесты апи, которые работают не через openapi тул.

Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.
Итого — а хрен его знает, чего ждать у них.

P>>По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.

·>Что значит "нужна"? Как именно они её будут использовать? Чтобы вызывать твой сервис можно использовать банальный curl.

Как именно
1. есть тулы для работы с опен апи, для тестов
2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.
3. могут и руками наструячить

P>>Что бы убедиться, что апи работает согласно требованиям.

·> Требования _задаются_ в FRD.

От апи есть вполне конкретные ожидания. Это часть требований.

> Сгенерённая по коду схема может лишь показать, что works as coded


Это всё равно наши ожидания. И нужно тестировать апи в явном виде.

P>>·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.

P>>Попробовали, получили отстой. Дальше что?
·>Т.е. вы поняли что у клиентов тоже будет получаться отстой. И норм. Гы.

Именно, если они возьмут генераторы и подкинут им рукописный манифест, то будет отстой. Элментарно — каждый генератор поддерживает некоторое подмножество фич опенАпи.
А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.
Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.

P>>То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике

·>Она отсутсвует потому что swashbuckle её не умеет добавлять.

Это уже дело десятое. Главное, что хорошего кодогенератора нет.

P>>Как ты этот вопрос обойдешь ручным набиванием схемы?

·>Просто впишешь семантическую метадату в схему.

Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы

P>>Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.

·>И? Имя-то будет?

Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.

P>>Эта спека нужна для того, что бы люди могли твой сервис использовать.

·>Конкретно рассказывай. Нужна для чего? Чтобы просто сервис использовать можно сделать тупо curl.

Уже много раз рассказал. Не понимаю твои вопросы.

P>>Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали

·>Сам-то веришь?

Факт в том, что мы не знаем происхождение того файла. Там точно не с апи проблема.
Re[48]: Догонит ли net java?
От: · Великобритания  
Дата: 16.12.22 22:45
Оценка:
Здравствуйте, Pauel, Вы писали:

P>·>Это всё донельзя элементарно. Например, если тебе нужно сгенерировать interface MyApi {void m1(); void m2();} Кладёшь рядом файлик class ExpectedApiImpl implements MyApi{@Override m1(); @Override m2();} и получаешь ошибки компиляции если генератор что-то "забудет".

P>Детский лепет. Кто будет этот класс генерить? Тот же генератор или еще один генератор? То есть, как понять, может тут должен быть метод m0 или m3
P>Или, наоборот, одно из 1 или 2 быть не должно.
Зачем его генерить? Цель теста проверить, что генератор генерит то, что мы ожидаем он должен генерить. Пишем образец и ассертим что результат совпадает с образцом.
Почему-то написать образцовый кусок схемы ты проверить в состоянии на валидность и корректность (как кстати?), а кусок кода на шарпе (который элементарно проверить не только компилятором, но даже тесты написать!) — прям затык в мозгу, и ничего не понимаешь.

P>>>Они это апи покупают, делают вызовы.

P>·>Зачем им именно _схема_? Сгенерите им javadoc|аналог по вашему коду и вперде.
P>Они сами просят.
Зачем они просят-то?

P>>>Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.

P>·>Это не сложнее схемогенератора. И явно проще, чем схемогенератор+кодогенератор.
P>Ровно наоборот — у меня есть с чем сравнивать. Кодогенератор писать сложнее, тяжело мейнтейнить, и его крайне тяжело тестировать.
P>А вот обложить тестами генератор схемы — это вообще дело плёвое, чисто юнит тесты
Да тоже самое. Просто инвертируешь.

P>
P>    @Api('v2/api')
P>    @Use(Correlation, Hooks)
P>    class Api {
P>       @Get()
P>       @ResponseHeaders()
P>       method(@IsValid(idSchema) @Query('id') id:string, @RequestId() requestId?:string):Result<Entity>;
P>    }

Вот это и положи в expected output теста.
А тест будет просто наоборот:
P>...
P>test('should generate interface', () => {

P>    expect(generate({"v2/api": {"get": {"operationId": "method", "parameters":{ ["name": "id", "in": "query"]...}}})).to.eq(file("exppected/Api.cs"));
P>});
P>



P>>>Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.

P>·>Что они будут делать со схемой, которая даже с трудом парсится?
P>Наша нормально парсится.
Что они будут делать со схемой?

P>>>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?

P>·>Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.
P>Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.
Аналог твоего "class Api" с навешанными аннотациями. Только интерфейс вместо класса. Или какой ещё клиентский код ты имеешь в виду? В любом случае — код это просто код, который можно скомпилять и даже выполнить и заасертить резултат.

P>>> Или что нет двух методов, которые быть должны. Код то компилится!

P>·>Можно даже банально набрать код в IDE, который хочешь чтобы сгенерировался, коммитишь как образец и пишешь тест посимвольного сравнения.
P>Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.
Руками накидать образец для теста же. Другие догадались давным давно.

P>>>Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.

P>·>Для этого есть тесты апи, которые работают не через openapi тул.
P>Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.
P>Итого — а хрен его знает, чего ждать у них.
Как они будут использовать опенапи? Вот пишут они клиента на... ээ.. допустим go. Куда они впихнут спеку, чтобы её использовать?

P>>>По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.

P>·>Что значит "нужна"? Как именно они её будут использовать? Чтобы вызывать твой сервис можно использовать банальный curl.
P>Как именно
P>1. есть тулы для работы с опен апи, для тестов
Ну это не для них, а для вас. Демка, чтобы сейлзы могли впаривать ваш эээ... продукт. В свой код они не смогут встроить, т.к.:

P>2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.

Ты сам заявил, что не смогут: "опробовали, получили отстой.". Ночной Смотрящий тоже говорил, что пробовал с тем же результатом.
А вот если бы вы сами использовали кодогенератор, это было бы вашей заботой и отстоя было бы хоть чуточку меньше, eat your own dog food.

P>3. могут и руками наструячить

Угу. О чём я и говорю.

P>>>Что бы убедиться, что апи работает согласно требованиям.

P>·> Требования _задаются_ в FRD.
P>От апи есть вполне конкретные ожидания. Это часть требований.
Так это ничего не докажет. Вы из кода генерите тесты самого кода. Порочный круг.

P>>>·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.

P>>>Попробовали, получили отстой. Дальше что?
P>·>Т.е. вы поняли что у клиентов тоже будет получаться отстой. И норм. Гы.
P>Именно, если они возьмут генераторы и подкинут им рукописный манифест, то будет отстой. Элментарно — каждый генератор поддерживает некоторое подмножество фич опенАпи.
P>А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.
P>Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.
Задумка хорошая, но не работает.

P>>>То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике

P>·>Она отсутсвует потому что swashbuckle её не умеет добавлять.
P>Это уже дело десятое. Главное, что хорошего кодогенератора нет.
Куда дели-то? Вот взял я swagger-codegen-cli.jar и сгенерил для https://github.com/googlemaps/openapi-specification всё завелось, и клиента и сервера под спринг и под котлин. Теперь могу спокойно вписывать логику в клиента и наваять местный стаб-сервер для тестов.

P>>>Как ты этот вопрос обойдешь ручным набиванием схемы?

P>·>Просто впишешь семантическую метадату в схему.
P>Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы
Кодогенератор умеет не больше, чем есть в спеке. И не меньше.

P>>>Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.

P>·>И? Имя-то будет?
P>Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.
И все они gpl и не позволяют шаблоны подправлять? Врёшь.

P>>>Эта спека нужна для того, что бы люди могли твой сервис использовать.

P>·>Конкретно рассказывай. Нужна для чего? Чтобы просто сервис использовать можно сделать тупо curl.
P> Уже много раз рассказал. Не понимаю твои вопросы.
Не рассказывал, а отмазывался "просят".

P>>>Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали

P>·>Сам-то веришь?
P>Факт в том, что мы не знаем происхождение того файла. Там точно не с апи проблема.
Да что там гадать-то? Очевидно же https://stackoverflow.com/questions/66909557/swashbuckle-is-generating-an-invalid-json-with-system-collections-generic-keyval Схемагенератор же просто и удобно... В апи понаписали генерики, которые swashbuckle переварить не смог и вывалил какашку.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[49]: Догонит ли net java?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.12.22 14:09
Оценка:
Здравствуйте, ·, Вы писали:

·>Зачем его генерить? Цель теста проверить, что генератор генерит то, что мы ожидаем он должен генерить. Пишем образец и ассертим что результат совпадает с образцом.


Написал, покрыл тестами. Баги могут быть, или у тебя и здесь багов не бывает?
А раз баги бывают, то как ты будешь детектить, что вдруг сгенерилось не то? Упс!
А со схемой можно это вопрос решить разными способами.

P>>Они сами просят.

·>Зачем они просят-то?

Используют для генерации, для тестов, итд.

P>>
P>>    @Api('v2/api')
P>>    @Use(Correlation, Hooks)
P>>    class Api {
P>>       @Get()
P>>       @ResponseHeaders()
P>>       method(@IsValid(idSchema) @Query('id') id:string, @RequestId() requestId?:string):Result<Entity>;
P>>    }
·>

·>Вот это и положи в expected output теста.

Так себе идея. Кодогенератору надо дать выхлоп в виде пакета, модуля или даже целого солюшна, с депенденсами, помкой и прочими приседаниями. Соответственно, сравнивать не кусочек текста, а дерево файлов. И это уже не хухры мухры — долго и муторно.

·>А тест будет просто наоборот:


Крайне хрупкий тест, т.к. если ты вдруг поменял мелочь, у тебя все тесты вдруг упали, и надо обновлять не фрагменты кода, а вообще всё.
Например — твой генеренный код использует кое какие депенденсы. Упс — часть из них протухла. Гы-гы, меняй шаблоны. Фиксай все файлы заготовок для тестов.
В этом плане схема вещь достаточно стабильная, меняется куда реже, чем генератор кода и шаблоны к нему.

P>>Наша нормально парсится.

·>Что они будут делать со схемой?

Подкидывают своим тулам, для тестов или генерации клиентов под свои платформы.

P>>>>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?

P>>·>Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.
P>>Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.
·>Аналог твоего "class Api" с навешанными аннотациями. Только интерфейс вместо класса.

Алё — ты читаешь вообще? — этот класс и есть полнофункциональный клиент, и он же есть описание АПИ.
Вот так вызывается
const new api = new API();

return api.method('an id');

И для этого мне все что нужно — только описать апи, как выше.

P>>Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.

·>Руками накидать образец для теста же. Другие догадались давным давно.

В том то и дело, что давным давно — это подход 90х...00х
Сейчас можно иначе

P>>Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.

P>>Итого — а хрен его знает, чего ждать у них.
·>Как они будут использовать опенапи? Вот пишут они клиента на... ээ.. допустим go. Куда они впихнут спеку, чтобы её использовать?

Очевидно — для го есть генератор который их устраивает. Для них это нормально, т.к. для них цикл разработки и так медленный, они получают обновления со скоростью наших релизов, можно не париться.
А вот у нас иначе — изменения апи во время разработки проходят много итераций, и здесь хочется получить результат максимально быстро
1. фиксанул сервис, проверил, что работает
2. обложил аннотациями, и получил апи
Теперь всё, кто зависит от этого сервиса вынуждены перекомпилироватся, и никакими хитростями это не получится обойти.
А если schema-first, то все иначе — пол-проекта работают как ни в чем не бывало "а у нас и так палит" и в итоге фиаско

P>>1. есть тулы для работы с опен апи, для тестов

·>Ну это не для них, а для вас. Демка, чтобы сейлзы могли впаривать ваш эээ... продукт. В свой код они не смогут встроить, т.к.:

Медленно — у них. Как работают сейлзы — ты не в курсе, не надо тащить отсебятину.

P>>2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.

·>Ты сам заявил, что не смогут: "опробовали, получили отстой.". Ночной Смотрящий тоже говорил, что пробовал с тем же результатом.

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

P>>От апи есть вполне конкретные ожидания. Это часть требований.

·>Так это ничего не докажет. Вы из кода генерите тесты самого кода. Порочный круг.

Не из кода, а из документации.

P>>А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.

P>>Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.
·>Задумка хорошая, но не работает.

Работает!

P>>Это уже дело десятое. Главное, что хорошего кодогенератора нет.

·>Куда дели-то? Вот взял я swagger-codegen-cli.jar и сгенерил для https://github.com/googlemaps/openapi-specification всё завелось, и клиента и сервера под спринг и под котлин. Теперь могу спокойно вписывать логику в клиента и наваять местный стаб-сервер для тестов.

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

P>>Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы

·>Кодогенератор умеет не больше, чем есть в спеке. И не меньше.

Гораздо больше, и в этом проблема.

P>>Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.

·>И все они gpl и не позволяют шаблоны подправлять? Врёшь.

У разных разные проблемы. Расширяемость, конфигурация, лицензия, стабильность, архитектура выхлопа, фремворк выхлопа, поддерживаемые фичи опенапи.

·>Да что там гадать-то? Очевидно же https://stackoverflow.com/questions/66909557/swashbuckle-is-generating-an-invalid-json-with-system-collections-generic-keyval Схемагенератор же просто и удобно... В апи понаписали генерики, которые swashbuckle переварить не смог и вывалил какашку.


ну ок — генеренный код. Сгенерировали хрень, проблема в том, что работа наот..сь. Такой подход и в ручном исполнении дает паскудство.
Re[50]: Догонит ли net java?
От: · Великобритания  
Дата: 18.12.22 11:43
Оценка:
Здравствуйте, Pauel, Вы писали:

P>·>Зачем его генерить? Цель теста проверить, что генератор генерит то, что мы ожидаем он должен генерить. Пишем образец и ассертим что результат совпадает с образцом.

P>Написал, покрыл тестами. Баги могут быть, или у тебя и здесь багов не бывает?
P>А раз баги бывают, то как ты будешь детектить, что вдруг сгенерилось не то? Упс!
Ну пофиксишь багу, сгенеришь другое. В чём аргумент-то?

P>А со схемой можно это вопрос решить разными способами.

Какими? И почему эти же способы не подходят для кодогенерации?

P>>>Они сами просят.

P>·>Зачем они просят-то?
P>Используют для генерации, для тестов, итд.
Почему у вас генерация не работает, у Ночного Смотрящего не работает, а у них работает?

P>·>Вот это и положи в expected output теста.

P>Так себе идея. Кодогенератору надо дать выхлоп в виде пакета, модуля или даже целого солюшна, с депенденсами, помкой и прочими приседаниями. Соответственно, сравнивать не кусочек текста, а дерево файлов. И это уже не хухры мухры — долго и муторно.
Честно говоря, не вижу проблемы. Пройтись по списку файлов и сделать сравнение — вопрос десятки строчек кода. Особенно с учётом того, что выхлоп можно проверить банально запустив билд и тест солюшена. Способы валидации сгенерённой схемы — ты так и не рассказал. Вот создатели swashbuckle не смогли осилить вменяемую схемогенерацию. А в том же swaggergen около сотни кодогенераторов в различные яп и платформы.

P>·>А тест будет просто наоборот:

P>Крайне хрупкий тест, т.к. если ты вдруг поменял мелочь, у тебя все тесты вдруг упали, и надо обновлять не фрагменты кода, а вообще всё.
Почему все? В сгенерённом коде несколько вполне определённых частей, которые меняются максимум при выходе новой версии openapi стандарта.

P>Например — твой генеренный код использует кое какие депенденсы. Упс — часть из них протухла. Гы-гы, меняй шаблоны. Фиксай все файлы заготовок для тестов.

Образец генерённого кода — обычный код. Его можно открыть в IDE и отрефакторить.

P>В этом плане схема вещь достаточно стабильная, меняется куда реже, чем генератор кода и шаблоны к нему.

Верно, если ты под схемой полагаешь стандарт схемы. Ибо набор метаданных и аннотаций ЯП ничем не ограничен, ничем не валидируется. А openapi по сравнению с c# — донельзя примитивен. Язык разметки по определению проще общего языка программирования. Поэтому распаристь редкоменяемую схему и сгенерить примитивный код — гораздо проще, чем парсить код, который постоянно меняется и туда кто угодно может вписывать что угодно.

P>>>Наша нормально парсится.

P>·>Что они будут делать со схемой?
P>Подкидывают своим тулам, для тестов или генерации клиентов под свои платформы.
Ок. Т.е. почему-то у них кодогенерация работает, у вас нет, у Ночного Смотрящего тоже нет. Почему?

P>>>Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.

P>·>Аналог твоего "class Api" с навешанными аннотациями. Только интерфейс вместо класса.
P>Алё — ты читаешь вообще? — этот класс и есть полнофункциональный клиент, и он же есть описание АПИ.
Генерируемый интерфейс — это отражение спеки — сигнатуры методов, аннотации, маппинги, помимо интерфейса ещё дто-шки.
У интерфейса будет две реализации — одна на сервере (тот самый твой class API, но без аннотаций и прочего шлака, банальный implements) и вторая реализация на клиенте — сгенерённая, которая вызовы методов сериализует в rest. См. у меня тут
Автор: ·
Дата: 14.12.22
примерчик.

P>Вот так вызывается

P>return api.method('an id');
Это только клиентская часть. Скучно. И неясно как ты клиентам предлагаешь мокать в юнит-тестах этот твой "class API".

P>И для этого мне все что нужно — только описать апи, как выше.

Угадай, что значит последняя буква в аббревиатуре "апи".

P>>>Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.

P>·>Руками накидать образец для теста же. Другие догадались давным давно.
P>В том то и дело, что давным давно — это подход 90х...00х
P>Сейчас можно иначе
Да и тогда делали иначе. Генерили из visual basic какой-нибудь idl.

P>>>Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.

P>>>Итого — а хрен его знает, чего ждать у них.
P>·>Как они будут использовать опенапи? Вот пишут они клиента на... ээ.. допустим go. Куда они впихнут спеку, чтобы её использовать?
P>Очевидно — для го есть генератор который их устраивает. Для них это нормально, т.к. для них цикл разработки и так медленный, они получают обновления со скоростью наших релизов, можно не париться.
P>А вот у нас иначе — изменения апи во время разработки проходят много итераций, и здесь хочется получить результат максимально быстро
P>1. фиксанул сервис, проверил, что работает
P>2. обложил аннотациями, и получил апи
P>Теперь всё, кто зависит от этого сервиса вынуждены перекомпилироватся, и никакими хитростями это не получится обойти.
P>А если schema-first, то все иначе — пол-проекта работают как ни в чем не бывало "а у нас и так палит" и в итоге фиаско
Я не понимаю почему тот же подход не применим. Поменяли схему — все вынуждены перекомпилиться, ведь это даёт гарантированную совместимость.

P>>>2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.

P>·>Ты сам заявил, что не смогут: "опробовали, получили отстой.". Ночной Смотрящий тоже говорил, что пробовал с тем же результатом.
P>Рандомную спеку — нет, не смогут. А вот выхлоп нашего генератора — смогут, т.к. он автоматически валидирует многие вещи, указывает, что должно, а чего не должно быть.
Или не указывает, т.к. может быть столько всего, что распознать может быть, что не может — неалгоритмизируемая задача, даже теоретически. В случае спеки у тебя явно задано, что быть может. Всё что не по спеке — не может.

P>Соответственно, новых девелоперов не надо учить "как именно нужно писать спеку что бы у тех ребят было всё хорошо".

Ну вот тех ребят, создающих swashbuckle и ребят из moedelo никто и не научил.

P>>>От апи есть вполне конкретные ожидания. Это часть требований.

P>·>Так это ничего не докажет. Вы из кода генерите тесты самого кода. Порочный круг.
P>Не из кода, а из документации.
Какой документации?

P>>>А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.

P>>>Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.
P>·>Задумка хорошая, но не работает.
P>Работает!
Как минимум — не всегда работает. Например, у Ночного Смотрящего.

P>>>Это уже дело десятое. Главное, что хорошего кодогенератора нет.

P>·>Куда дели-то? Вот взял я swagger-codegen-cli.jar и сгенерил для https://github.com/googlemaps/openapi-specification всё завелось, и клиента и сервера под спринг и под котлин. Теперь могу спокойно вписывать логику в клиента и наваять местный стаб-сервер для тестов.
P>Ты сам себя высек — вот эта спека ажно 2.6мб. Судя по контенту — выхлоп какого то сборщика. То есть, товарищи из гугла постарались сгенерить спеку так, что бы её можно было без проблем скармливать генератору.
P>Наши консумеры поступают ровно так же, как и ты с гугловым апи.
Не понял где. Это целый репо, с исходниками спеки.
Суть в том, что спека пишется по исходному стандарту openapi. И поэтому получается стандартной по определению. При схемогенерации, нужно парсить мету вашего конкретного кода, который пишется как попало. Поэтому требуется распознавать что понаписаное в шарпе ложится в стандарт. Это гораздо сложнее. Вы можете в шарпе писать как попало, реализуя любые свои идеи. Но если они не выражаются в виде вменяемой операпи спеки, то возникнут проблемы, притом не у вас непосредственно, а у ваших клиентов.

P>>>Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы

P>·>Кодогенератор умеет не больше, чем есть в спеке. И не меньше.
P>Гораздо больше, и в этом проблема.
Нет, больше просто неоткуда брать, стандарт очень ограничен. Например, в опенапи нет генериков, поэтому ты банально не сможешь вписать ничего такого. В шарпе генерики есть. И если пытаться потом из этого что-то нагенерить — будут проблемы. В этом и суть dsl — явно ограничить возможности, чтобы гарантировать юзабельность.

P>>>Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.

P>·>И все они gpl и не позволяют шаблоны подправлять? Врёшь.
P>У разных разные проблемы. Расширяемость, конфигурация, лицензия, стабильность, архитектура выхлопа, фремворк выхлопа, поддерживаемые фичи опенапи.
По твоему заявлению у ваших клиентов таких проблем нет. Почему?

P>·>Да что там гадать-то? Очевидно же https://stackoverflow.com/questions/66909557/swashbuckle-is-generating-an-invalid-json-with-system-collections-generic-keyval Схемагенератор же просто и удобно... В апи понаписали генерики, которые swashbuckle переварить не смог и вывалил какашку.

P>ну ок — генеренный код. Сгенерировали хрень, проблема в том, что работа наот..сь. Такой подход и в ручном исполнении дает паскудство.
Ок, так и запишем swashbuckle сделан наот..сь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.