Объявляю структуру в специальном объекте, который описывает поля джейсона.

Это удобно? Я так понял, любая операция с объектом выглядит примерно как json.get(fieldDescriptor)?

я видел что делают скалисты, у них в dto методы fromJson() и toJson(), которые соответственно принимают и отдают JsonObject

Я так на Java делал. Устал писать этот однообразный бойлерплейт.

Нет, компилятор за магию не считается, у него предсказуемое поведение.

да ладно? даже если код генерится?

Я так на Java делал. Устал писать этот однообразный бойлерплейт.

ObjectMapper то чем не угодил? никакого бойлерплейта....

да ладно? даже если код генерится?

Даже если код генерится. Генерящийся код всё равно строго специфицирован и так же проходит проверку времени компиляции.

ObjectMapper то чем не угодил? никакого бойлерплейта....

Аннотации же. Я сейчас им обычно и пользуюсь.

Это удобно? Я так понял, любая операция с объектом выглядит примерно как json.get(fieldDescriptor)?

Нет, не так. Объявляется структура: object User { val Name = "name" let string val Surname = "surname" let string } создаётся объект, который вычитывает поля через обобщённый интерфейс: val user = StructSnapshot(User, JsonDataSource(JsonReader(json))) доступ: val name = user[User.Name]

jibx в руки фанатам такого подхода

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

Нет, не так. Объявляется структура: object User { val Name = "name" let string val Surname = "surname" let string } создаётся объект, который вычитывает поля через обобщённый интерфейс: val user = StructSnapshot(User, JsonDataSource(JsonReader(json))) доступ: val name = user[User.Name]

еще чуть чуть докрутить и будут линзы

Нет, не так. Объявляется структура: object User { val Name = "name" let string val Surname = "surname" let string } создаётся объект, который вычитывает поля через обобщённый интерфейс: val user = StructSnapshot(User, JsonDataSource(JsonReader(json))) доступ: val name = user[User.Name]

обобъённый - это опечатка в слове "обобщённый" или "объебошенный"? ) Троллю, отвечать не надо

Нет, не так. Объявляется структура: object User { val Name = "name" let string val Surname = "surname" let string } создаётся объект, который вычитывает поля через обобщённый интерфейс: val user = StructSnapshot(User, JsonDataSource(JsonReader(json))) доступ: val name = user[User.Name]

Ну я примерно об этом. С вложенными объектами и списками не начинается ад?

обобъённый - это опечатка в слове "обобщённый" или "объебошенный"? ) Троллю, отвечать не надо

спасибо, исправил)

жалко помер https://github.com/jibx/jibx

Ну я примерно об этом. С вложенными объектами и списками не начинается ад?

пока не знаю

Ну я примерно об этом. С вложенными объектами и списками не начинается ад?

А тут мы из линз начинаем телескопы собирать

еще чуть чуть докрутить и будут линзы

где про них внятно почитать?

jibx в руки фанатам такого подхода

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

я видел что делают скалисты, у них в dto методы fromJson() и toJson(), которые соответственно принимают и отдают JsonObject

чагооооо

У нас тайпклассы

Как раз в scala уже давно разделили dto и описания для сериализации/десириализации

Вообще, работать с JsonObject'ами — метод, по отстойности перегоняющий рефлексию.

Как раз в scala уже давно разделили dto и описания для сериализации/десириализации

Можно примеры?

где про них внятно почитать?

Ну вот нагуглилось вроде https://medium.com/@dtipson/functional-lenses-d1aba9e52254

Вообще, работать с JsonObject'ами — метод, по отстойности перегоняющий рефлексию.

В малых масштабах вполне норм, как по мне

В малых масштабах вполне норм, как по мне

Какие плюсы в сравнении хоть с чем-нибудь?

Можно примеры?

Ну мы пишем условно вот так: case class Foo(bar: Int, baz: String) object Foo { implicit val fooReader: JsonReader[Foo] = jsonReader[Foo] // тут макросы, но можно и руками implicit val fooReader: JsonWriter[Foo] = jsonWriter[Foo] } либо эквивалентную запись @derive(jsonReader, jsonWriter) case class Foo(bar: Int, baz: String)

Ну мы пишем условно вот так: case class Foo(bar: Int, baz: String) object Foo { implicit val fooReader: JsonReader[Foo] = jsonReader[Foo] // тут макросы, но можно и руками implicit val fooReader: JsonWriter[Foo] = jsonWriter[Foo] } либо эквивалентную запись @derive(jsonReader, jsonWriter) case class Foo(bar: Int, baz: String)

а, ясно, compile-time reflection :)

А потом в коде что то вроде someJsonString.jsonAs[Foo]

*прилетел*

https://arrow-kt.io/docs/optics/lens/

*улетел*

а, ясно, compile-time reflection :)

Ну говорю же можно и руками)

Ну вот нагуглилось вроде https://medium.com/@dtipson/functional-lenses-d1aba9e52254

спасибо, пытаюсь вникнуть

Главное что это уже давно разделено, котлеты отдельны мухи отдельно - типы отдельны описания отдельно

риальне у меня линзы получились, забавно

а, ясно, compile-time reflection :)

compile time reflection - оксюморон. In computer science, reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime. https://en.wikipedia.org/wiki/Reflection_(computer_programming)

compile time reflection - оксюморон. In computer science, reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime. https://en.wikipedia.org/wiki/Reflection_(computer_programming)

this https://t.me/kotlin_lang/86827

compile time reflection - оксюморон. In computer science, reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime. https://en.wikipedia.org/wiki/Reflection_(computer_programming)

Ну у нас это реально называется reflection api :)

Ну у нас это реально называется reflection api :)

У вас, это где?

В скалке

Какие плюсы в сравнении хоть с чем-нибудь?

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

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

Дак я и не предлагаю спорить. Я вижу минусы: уродливый API и феерическое потребление памяти. Вот и интересуюсь плюсами. Про тесты аргумент принял — согласен. это может быть удобнее, чем объявлять отдельные классы.

В скалке

Ну вообще compile time reflection - это code instrumentation. Работа с AST средствами языка на этапе компиляции (макросы всякие и иже с ним)

Вообще, работать с JsonObject'ами — метод, по отстойности перегоняющий рефлексию.

А есть какие-либо решения, чтобы не работать с JsonObject, если прилетает жсон определенной структуры, но имя объектов динамическое?

Ну вообще compile time reflection - это code instrumentation. Работа с AST средствами языка на этапе компиляции (макросы всякие и иже с ним)

о них и речь

А есть какие-либо решения, чтобы не работать с JsonObject, если прилетает жсон определенной структуры, но имя объектов динамическое?

HashMap?..

о них и речь

Ну reflection - это другое. Это работа с мета информацией о типах в рантайме

Дак я и не предлагаю спорить. Я вижу минусы: уродливый API и феерическое потребление памяти. Вот и интересуюсь плюсами. Про тесты аргумент принял — согласен. это может быть удобнее, чем объявлять отдельные классы.

Ну а что ещё можно ожидать от формата обмена данными из мира JS? API примерно такой же, как у Map.

У вас тут можно мпрашивать вопросы по разработке под андроид?

У вас тут можно мпрашивать вопросы по разработке под андроид?

@android_ru

Ну а что ещё можно ожидать от формата обмена данными из мира JS? API примерно такой же, как у Map.

Да ничего хорошего, конечно. :)

Ну а что ещё можно ожидать от формата обмена данными из мира JS? API примерно такой же, как у Map.

Так JSON и есть словарь (Map). Какой у него ещё API может быть?

Так JSON и есть словарь (Map). Какой у него ещё API может быть?

Или лист. Или стринг. Или Number.

Так JSON и есть словарь (Map). Какой у него ещё API может быть?

Люди, пишущие на Java, привыкли к статически типизированным объектам и зачастую натягивают JSON на них, ибо удобнее.

Или лист. Или стринг. Или Number.

Унифицированно - все равно Map

Унифицированно - все равно Map

Валидный JSON: "wtf". Где здесь Map?

Или лист. Или стринг. Или Number.

Ок. data Json = List | String | Number | {"<key_name>": Json,... }

и ещё Boolean и null, но не суть

Валидный JSON: "wtf". Где здесь Map?

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

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

["wtf", "foo"] - тоже валидный JSON и тоже не объект

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

в корне примитивы встречаются редко, а массивы — вполне

["wtf", "foo"] - тоже валидный JSON и тоже не объект

А вот массивы - это уже частный случай мап

По-моему, есть даже парсеры, которые умеют json-массивы перекидывать в мапы вида {1:"...", 2:"..."}

По-моему, есть даже парсеры, которые умеют json-массивы перекидывать в мапы вида {1:"...", 2:"..."}

казалось бы, наху^Wзачем?

А вот массивы - это уже частный случай мап

Ну так-то да. Массивы можно рассматривать, как Map с целыми, идущими подряд ключами

в корне примитивы встречаются редко, а массивы — вполне

Массив в корне - плохая идея. Если это API, сильно ограничивает гибкость.

Массив в корне - плохая идея. Если это API, сильно ограничивает гибкость.

Заворачивать всё в объект — плохая идея. На фронтах лепят страшные костыли чтобы разворачивать.

откуда инфа

откуда инфа

от фронтов, лол Сколько проектов не видел, везде есть что-то типа data class SomethingResponse { @Json("result") val result: List<SomeObject> }

Заворачивать всё в объект — плохая идея. На фронтах лепят страшные костыли чтобы разворачивать.

Интересно, что за костыли такие

Интересно, что за костыли такие

сообщением выше

Потому что приходит пресловутый объект { "result": [ ... ] }

Не вижу ничего костыльного. Завтра там появится ещё одно поле, и обёртка уже не будет выглядеть вырожденной.

да это жостка. массив в корне json = норма

завернуть респонз апишки в конверт с метаинфой = норма

Не вижу ничего костыльного. Завтра там появится ещё одно поле, и обёртка уже не будет выглядеть вырожденной.

добавляешь поле — делай новый эндпоинт

передать метаинфу в заголовках = норма

остальное от лукавого

добавляешь поле — делай новый эндпоинт

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

добавляешь поле — делай новый эндпоинт

инфа о версионировании апишки в заголовке, не благодари )

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

Это не ровное место, а изменение return type.

Это не ровное место, а изменение return type.

Ну так чтобы его не менять, а расширять лучше и возвращать объект изначально. А в Java ещё и будет меньше заморочек с дженериками при использовании всяких мапперов, в качестве бонуса.

Ну так чтобы его не менять, а расширять лучше и возвращать объект изначально. А в Java ещё и будет меньше заморочек с дженериками при использовании всяких мапперов, в качестве бонуса.

Так и из методов возвращай тогда Object или Map<String, *>

Так и из методов возвращай тогда Object или Map<String, *>

Попахивает JS. И тогда в приложении не будет ни одного места, где нормально описан формат ответа.

Попахивает JS. И тогда в приложении не будет ни одного места, где нормально описан формат ответа.

Примерно к этому я клоню. (JSON не может не попахивать JS, но всегда можно сделать ещё хуже)

добавляешь поле — делай новый эндпоинт

Вот есть у меня /api/v1/results. Как называть новый endpoint, v2? И так на каждое подобное изменение?

Вот есть у меня /api/v1/results. Как называть новый endpoint, v2? И так на каждое подобное изменение?

всё зависит от того, что и зачем добавилось туда

Вот есть у меня /api/v1/results. Как называть новый endpoint, v2? И так на каждое подобное изменение?

добавление новых полей это обратно совместимая хрень. а удаление уже нет

есть вообще отличная практика запрашивать на стороне клиента список требуемых полей

Примерно к этому я клоню. (JSON не может не попахивать JS, но всегда можно сделать ещё хуже)

API всегда можно описать и натянуть на DTO, тогда JS не будет пахнуть

API всегда можно описать и натянуть на DTO, тогда JS не будет пахнуть

а ты предлагаешь натянуть на Map<String, *>

есть вообще отличная практика запрашивать на стороне клиента список требуемых полей

Как, в реальном мире чтоли? Да нет, не работает такая практика

есть вообще отличная практика запрашивать на стороне клиента список требуемых полей

Да. Полей объекта, конечно же.

Как, в реальном мире чтоли? Да нет, не работает такая практика

даже ВКонтакте (sic!) поддерживает такое

а ты предлагаешь натянуть на Map<String, *>

Ну вообще-то нет. Как раз таки на FooResponse