Здравствуйте, ·, Вы писали:
·>Здравствуйте, VladiCh, Вы писали:
vsb>>>Я про жаву а не про ломбок. VC>>Ну Lombok это просто плагин к компилятору Java по сути, а не что-то отдельное. ·>Неправда. ·>
Lombok is a huge hack that will only compile using javac or eclipse's compiler.
Не понял, что в том что я сказал неправда? Используется стандартный механизм "JSR 269 Pluggable Annotation Processing API"
То что во внутренней логике у него хак на хаке — это здесь вторичное. Большинство стандартных билд механизмов поддерживается — https://projectlombok.org/contributing/lombok-execution-path
Здравствуйте, 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 и делает его плагином к компилятору
Здравствуйте, 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 работал, используется хак в код компилятора.
Здравствуйте, 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 это не плагин к компилятору. Пусть он и лезет в потроха самого компилятора чтобы делать то что он делает.
Здравствуйте, 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 же приходится подпиливать на каждую реализацию и иногда даже версию компилятора.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 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 через стандартный интерфейс + определенное нестандартное вуду с его внутренностями.
Здравствуйте, 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 через стандартный интерфейс + определенное нестандартное вуду с его внутренностями.
То что Остап Бендер заявляет, что чтит уголовный кодекс, не делает его законопослушным гражданином.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>А я и не говорил что работает всегда. Зато когда оно работает ... ·>Хреново оно работает.
Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов. Во вторых, меньше интеграционного кода, меньше шансов сломать. В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.
·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически.
2023й год на дворе, очнись.
·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных.
Метаданные у вас не изобрели, понимаю.
·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание. Но зачем придумывать ещё один язык?..
Не надо изобретать — есть декларативные способы задания аспектов апи. Работают сами по себе, без приседаний. Они выдают метаданные. Подхватил метаданные — нагенерил хучь что хошь. Можешь генерить и тесты, и клиент, и солюшн для нового приложения, хоть скрипты деплоймента.
Манифест типа OpenAPI должен генерироватся каким протестированым надежным генератором по метаданным. Т.е. не руками писаться, а генерироваться!
Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Хреново оно работает. НС>Всегда хреново работает?
Угу. Другое дело, что иногда хреновый результат может быть всё ещё годным на практике.
НС>>>Нет, это результат кривого генератора. НС>·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически. НС>·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных. НС>·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание. НС>Ну вот, ты сам на все ответил.
Ага. Ведь гланды можно удалять через разные места.
НС>·> Но зачем придумывать ещё один язык?.. НС>Это наоборот, заставлять писать руками на 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, етс" — это всё разные способы сериализации.
НС>>>Разные модели — раз. НС>>>Разные модели — два. НС>·>Где что разное? Модели чего? НС>Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал.
Модели чего разные? Преобразовать чего к чему? Говори конкретно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
НС>>>А я и не говорил что работает всегда. Зато когда оно работает ... P>·>Хреново оно работает. P>Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов.
Ага-ага. И поэтому у вас всё постоянно валится и вам приходится в проде тестировать.
P>Во вторых, меньше интеграционного кода, меньше шансов сломать.
Потому что вы заблуждаетесь, что навешанные аннотации это не код и можно не тестировать. На самом деле, каждая повешанная аннотация — это точно такой же код, как и всё остальное, и требует соответствующих тестов.
P>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.
Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.
P>·>Дело в том, что "прямой" генератор описания по коду невозможно написать даже теоретически. P> 2023й год на дворе, очнись.
Ну математические теоремы ещё не научились опровергать.
P>·>Код — это тьюринг-полный яп, а описание — довольно примитивный язык разметки структур данных. P>Метаданные у вас не изобрели, понимаю.
Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.
P>·>Можно, конечно, придумать поверх яп какой-то набор правил и соглашений (которые как формализовать-то? как валидировать?), следуя которым будем писать код, по которому может сгенериться вменяемое описание. Но зачем придумывать ещё один язык?.. P>Не надо изобретать — есть декларативные способы задания аспектов апи.
Где они есть-то? Ссылочку на стандарт можно?
P>Работают сами по себе, без приседаний. Они выдают метаданные. Подхватил метаданные — нагенерил хучь что хошь. Можешь генерить и тесты, и клиент, и солюшн для нового приложения, хоть скрипты деплоймента. P>Манифест типа OpenAPI должен генерироватся каким протестированым надежным генератором по метаданным. Т.е. не руками писаться, а генерироваться! P>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.
Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>·>Хреново оно работает. НС>>Всегда хреново работает? ·>Угу.
Сильное заявление. Обоснования будут?
НС>>Ну вот, ты сам на все ответил. ·>Ага. Ведь гланды можно удалять через разные места.
Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает.
НС>>Это наоборот, заставлять писать руками на OpenAPI это придумывать еще один язык. ·>OpenAPI это уже существующий и стандартизованный язык.
Тем не менее это еще один язык.
НС>>Я ее уже смотрел. Это не отвечает на мои вопросы. ·>Ок. Отвечаю на этот вопрос: "API основанное на сценариях — частный случай?" ·>Понятия не имею откуда ты это взял
НС>>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
·> Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.
НС> Ничего не понял. API основанное на сценариях — частный случай?
НС>>·> и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.". НС>>Ну и? Какой тут бенефит от генератора? ·>В том, что писать будешь используя сгенерированный код
В чем бенефит?
·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.
Что нужно писать с нуля и почему? Почему не хватает средств реюза языка и нужен генератор?
НС>>·>Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю. НС>>Я говорю о генерации моделей, я с самого начала про это написал. Генерировать сериализаторы, по крайней мере в дотнете, не нужно. Они сами справляются. ·>Что такое генерация моделей?
Генерация классов C#/Java по какому то внешнему описанию не на C#/Java.
·> И с какой целью их генерировать?
Для описания метаданных в терминах компилятора строго типизированных язков.
·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации.
Нет конечно.
НС>>Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал. ·>Модели чего разные? Преобразовать чего к чему? Говори конкретно.
Здравствуйте, Pauel, Вы писали:
P>Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов. Во вторых, меньше интеграционного кода, меньше шансов сломать. В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.
В-четвертых средства обобщения полноценного мейнстримового языка на две головы выше любого "стандартного" местечкового языка. В-пятых инструментарий мейнстримового языка где то в стратосфере относительно инструментария для какого нибудь нишевого решения типа OpenAPI.
, выше уже приводил. Не можете даже шарп из шарпа заюзать, в итоге "писать клиентов нужно руками".
НС>>>Ну вот, ты сам на все ответил. НС>·>Ага. Ведь гланды можно удалять через разные места. НС>Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает.
Нет никакого богом данного языка описания модели, пока ты сам его не придумаешь. Ты ещё так и не ответил на вопросы: "как формализовать-то? как валидировать?".
НС>>>Это наоборот, заставлять писать руками на OpenAPI это придумывать еще один язык. НС>·>OpenAPI это уже существующий и стандартизованный язык. НС>Тем не менее это еще один язык.
В моей схеме это второй и последний язык, который в твоей схеме тоже есть. Только ты пытаешься генерить на этом языке из твоих аннотаций, которые по сути edsl, т.е. третий язык.
НС>>>Я ее уже смотрел. Это не отвечает на мои вопросы. НС>·>Ок. Отвечаю на этот вопрос: "API основанное на сценариях — частный случай?" НС>·>Понятия не имею откуда ты это взял НС>
НС>>>API должно быть ориентировано на сценарии, иначе это плохое API, неудобное.
НС>·> Я знаю. Ты сам стал рассматривать такое api. Я сразу заявил, что это частный случай.
НС>> Ничего не понял. API основанное на сценариях — частный случай?
Ну т.е. это ты сам придумал, т.к. ничего не понял. Про частный случай я сказал только вот тут про твой API с одинм методом-всемогутером:
НС>И вот тут нам генератор породит и на клиенте метод-всемогутор, который, конечно, обладает максимальной гибкостью, но при этом еще и максимально неудобен, потому что нет ни одного юзкейса где нужны были бы все фильтры.
Это довольно частный пример.
НС>>>·> и выше "Это довольно частный пример. Впрочем даже в этом случае, можно поверх метода-всемогутера написать соответствующие клиентские юзкейсы конкретного клиента.". НС>>>Ну и? Какой тут бенефит от генератора? НС>·>В том, что писать будешь используя сгенерированный код НС>В чем бенефит?
Ниже написал, после запятой.
НС>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля. НС>Что нужно писать с нуля и почему?
Вот по твоему же заявлению: "писать клиентов нужно руками".
НС>Почему не хватает средств реюза языка и нужен генератор?
Пусть дали тебе .proto-файл. Что делать будешь? Что реюзать?
НС>>>·>Лично я говорю о генерации кода по описаниям. А о чём говоришь ты — я не знаю. НС>>>Я говорю о генерации моделей, я с самого начала про это написал. Генерировать сериализаторы, по крайней мере в дотнете, не нужно. Они сами справляются. НС>·>Что такое генерация моделей? НС>Генерация классов C#/Java по какому то внешнему описанию не на C#/Java.
Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?
НС>·> И с какой целью их генерировать? НС>Для описания метаданных в терминах компилятора строго типизированных язков.
Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?
НС>·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации. НС>Нет конечно.
Почему? Есть спеки, которые описывают как конкретные сообщения преобразуются в конкретные байты и обратно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
НС>>>Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака. НС>·>Whatever, другое api может иметь другое описание и по нему тоже генериться код.
НС>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД.
а как предлагается написать модель, если требуется два вида табличек — основная и историческая ? историческую наследовать от основной ? а как там у орм потом с планами не поедет крыша от наследований ? и зачем на это тратить ресурсы, если внешняя приблуда может сгенерить модели без всякого наследования ?
Здравствуйте, ·, Вы писали:
P>>Наоборот — шикарно, цикл разработки сокращается в разы. Во первых, требует в разы меньше тестов. ·>Ага-ага. И поэтому у вас всё постоянно валится и вам приходится в проде тестировать.
Тесты в проде это признак отсутствия синдрома бога.
P>>Во вторых, меньше интеграционного кода, меньше шансов сломать. ·>Потому что вы заблуждаетесь, что навешанные аннотации это не код и можно не тестировать.
Наоборот, нужно, только не надо дублировать 100500 тестов либы которая для этого испольуется.
> На самом деле, каждая повешанная аннотация — это точно такой же код, как и всё остальное, и требует соответствующих тестов.
Парсер формата .proto тоже требует тестов. И это сторонняя либа. Соответсвенно в продукте нет необходимости заниматься дурью и дублирвать все тесты подобного рода.
А вот тесты апи всё равно надо делать, не важно чем ты это апи пропишешь. Или у вас и таких тестов тоже нет?
P>>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры. ·>Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.
Цикл разработки версии — месяцы, иногда и годы. И нужен быстрый способ менять апи в разработке.
·>Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.
А ты похоже не в курсе, что нет полноценного grpc для веба, т.к. браузер и особенно приложение унутре, не контролируют полностью протокол хттп. А вот где грпц играет — в изолированой сети, когда созданы специальные условия.
P>>Не надо изобретать — есть декларативные способы задания аспектов апи. ·>Где они есть-то? Ссылочку на стандарт можно?
grpcs это один из таких вариантов. Одна проблема — для веба не летает. А потому фремворки умеют все эти вещи.
еще есть graphql. И много чего есть. Фичи конкретного фремворка это эквивалентное решение.
P>>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс. ·>Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.
Пока что эта сила в веб вылезть не может. грпц это круто, только что делать в вебе? есть grpc-web, но это костыль и он убог.
Теоретически, когда grpc вылезет из своей конуры, это будет прорыв в вебе. Но шота предпосылок к этому не имеется.
Здравствуйте, 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, получить бонус и потом тратят время и деньги заказчиков на "писать клиентов нужно руками".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
, выше уже приводил. Не можете даже шарп из шарпа заюзать, в итоге "писать клиентов нужно руками".
Единичный баг как обоснование заявления с квантором всеобщности?
НС>>Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает. ·>Нет никакого богом данного языка описания модели
Зато есть основной рабочий язык разработчика.
НС>>Тем не менее это еще один язык. ·>В моей схеме это второй и последний язык,
Только в одном маленьком аспекте.
·>Только ты пытаешься генерить на этом языке из твоих аннотаций, которые по сути edsl, т.е. третий язык.
Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.
НС>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля. НС>>Что нужно писать с нуля и почему? ·>Вот по твоему же заявлению: "писать клиентов нужно руками".
И где здесь "с нуля"?
НС>>Почему не хватает средств реюза языка и нужен генератор? ·>Пусть дали тебе .proto-файл.
Пусть мне не давали .proto файл.
НС>>·>Что такое генерация моделей? НС>>Генерация классов C#/Java по какому то внешнему описанию не на C#/Java. ·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?
В том и проблема, что модель получается одна, хотя нужны разные.
НС>>·> И с какой целью их генерировать? НС>>Для описания метаданных в терминах компилятора строго типизированных язков. ·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?
Метаданные .NET -> генератор -> OpenAPI spec
НС>>·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации. НС>>Нет конечно. ·>Почему?
Потому что спецификация API это намного больше чем просто сериализация.
Здравствуйте, Gt_, Вы писали:
НС>>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД. Gt_>а как предлагается написать модель, если требуется два вида табличек — основная и историческая ? историческую наследовать от основной ?
Не понимаю какое это имеет оношение к обсуждаемому вопросу.
Gt_>а как там у орм потом с планами не поедет крыша от наследований ?
Ты меня с кем то перепутал. Я наоборот предлагал наследование не использовать по возможности.
НС>>>Ну то есть вместо того чтобы просто написать модель мы вынужденны, в силу недостаточной выразительности языка, описывать ее на каком то другом языке и прикручивать генератор. ЧТД. Gt_>>а как предлагается написать модель, если требуется два вида табличек — основная и историческая ? историческую наследовать от основной ?
НС>Не понимаю какое это имеет оношение к обсуждаемому вопросу.
Gt_>>а как там у орм потом с планами не поедет крыша от наследований ?
НС>Ты меня с кем то перепутал. Я наоборот предлагал наследование не использовать по возможности.
я ничего не путаю, именно ты собрался в рукопашную писать модели, пользуясь выразительностью языка (тм)
по мне, так очень необычный подход. потому и спрашиваю, вот в случае основной и исторической таблички, что предлагается — пользоваться той самой выразительностью языка и наследовать ? может для каждого понятие врукопашную перестукивать все поля, сначала для основной, потом для исторической ? пока это вопрос, понять, что в противовес DSL языку предлагается.
, выше уже приводил. Не можете даже шарп из шарпа заюзать, в итоге "писать клиентов нужно руками". НС>Единичный баг как обоснование заявления с квантором всеобщности?
"В свое время перебрали пачку генераторов" — вполне таки квантор всеобщности. Или ты имел в виду клиенты для этого конкретного сервиса? Или за два года этот самый единичный баг поправили наконец?
НС>>>Через гланды это когда вместо одного языка описания модели — целая пачка, потому что возможностей основного языка не хватает. НС>·>Нет никакого богом данного языка описания модели НС>Зато есть основной рабочий язык разработчика.
Ты говоришь о каком-то игрушечном проекте, видимо. В реальности одним ЯП ну никак не обойтись.
НС>>>Тем не менее это еще один язык. НС>·>В моей схеме это второй и последний язык, НС>Только в одном маленьком аспекте.
Что?
НС>·>Только ты пытаешься генерить на этом языке из твоих аннотаций, которые по сути edsl, т.е. третий язык. НС>Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.
Т.е. ты хочешь сказать, что можно наколбасить произвольный c# код и любому коду некий генератор может сгенерить юзабельную схему? Имя генератора в студию!
НС>>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля. НС>>>Что нужно писать с нуля и почему? НС>·>Вот по твоему же заявлению: "писать клиентов нужно руками". НС>И где здесь "с нуля"?
А с чего?
НС>>>Генерация классов C#/Java по какому то внешнему описанию не на C#/Java. НС>·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные? НС>В том и проблема, что модель получается одна, хотя нужны разные.
Разные модели чего? где? и для чего?
НС>>>Для описания метаданных в терминах компилятора строго типизированных язков. НС>·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных? НС>Метаданные .NET ->
Подробнее, что такое "Метаданные .NET"? Аннотации?
НС> генератор -> OpenAPI spec
Ок, ну допустим. А дальше? "писать клиентов нужно руками"?
НС>>>·>Притом, что "FIX, swagger, avro, protobuf, етс" — это всё разные способы сериализации. НС>>>Нет конечно. НС>·>Почему? НС>Потому что спецификация API это намного больше чем просто сериализация.
Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией, поэтому в контексте обсуждения это таки сериализация.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
2023й год на дворе, очнись.
