Comments 111
Оо, в этом месяце еще не было джейсона без кавычек и с комментариями.
Велосипеды — это наше всё!
Не знаете, как бы их найти тут? Я бы почитал про другие попытки, интересно.
«Свой JSON» действительно появляется тут чуть ли не каждый месяц. И количество плюсов у комментария выше показывает, что все кроме вас их видят.
Вот то, что я нашел за 5 минут:
https://habrahabr.ru/post/247473/
https://habrahabr.ru/post/269993/
https://habrahabr.ru/post/269461/
https://habrahabr.ru/post/130112/
https://habrahabr.ru/post/248147/
Вот то, что я нашел за 5 минут:
https://habrahabr.ru/post/247473/
https://habrahabr.ru/post/269993/
https://habrahabr.ru/post/269461/
https://habrahabr.ru/post/130112/
https://habrahabr.ru/post/248147/
Спасибо за ссылки!
Всё-таки есть и обратная сторона — вы, как и я, заинтересовались заголовком и тизером и зашли почитать. Вопрос — чего мы с вами ожидали от статьи? Лулзов? А может, всё-таки, надеемся что кто-то таки придумал более удобный формат? Если второе, то я думаю, попытки имеют право быть — почему нет?
Я, например, зашел посмотреть на проблему, которая привела к попытке создания своего формата. Если говорить про сериализацию, то ничего принципиально интересного в дополнительной типизации полей я не вижу, т. к. это усложняет десериализатор, но не даёт гарантий, что пришедший объект валиден (например, могут нарушаться какие-нибудь инварианты).
Ну и ради лулзов, ессно.
Ну и ради лулзов, ессно.
Автор пишет об излишестве кавычек (что ошибочно, ибо JSON позволяет в качестве ключа использовать {'i am a key': 'value'}), но в то же время хочет добавлять типы. Странно как-то.
Кавычки в KTV допустимы, как раз для таких случаев.
Если мы используем JSON, например, для передачи данных по сети, то это излишество.
Я вот об этом. Вас беспокоят лишние байты, но в то же время Вы говорите о том, что нужно передавать типы.
Типы передавать необязательно, это я тоже отметил. Также, байтики нужно не только передавать, но и писать.
Ещё строки не способствуют строгой типизации. Внутри JSON'а — часто объекты, объекты, которые парсятся в строго-типизированные языки. Строки маппить в строготипизированный язык тяжело (посмотрите, сколько парсеров JSON'а существует). Мне кажется, что если зажать этот формат несколько сильнее, то его проще будет редактировать, проще контролировать и работать с ним. Не в любом контексте, а в том, который я указываю.
Ещё строки не способствуют строгой типизации. Внутри JSON'а — часто объекты, объекты, которые парсятся в строго-типизированные языки. Строки маппить в строготипизированный язык тяжело (посмотрите, сколько парсеров JSON'а существует). Мне кажется, что если зажать этот формат несколько сильнее, то его проще будет редактировать, проще контролировать и работать с ним. Не в любом контексте, а в том, который я указываю.
Если JSON объект парсится в строго типизированном языке, то, скорее всего, существует контракт(модель). Т.е. принимающая сторона ожидает, что в проперти "name" будет лежать строка, а в проперти "age" целочисленный тип данных.
Это правда, но часто модель приходится делать уже по существующим JSON'ам (которые делались для сайта, например), поэтому изначально контракты отсутствовали, что приводит к очень, очень сложным моделям для парсинга. Как я отметил в статье, например, разные типы кладутся в коллекции или названия полей недопустимы для целевого языка.
Опять же, ссылки на объекты часто бывают полезны.
Опять же, ссылки на объекты часто бывают полезны.
Впрочем, использование такого значения в качестве ключа — порочная практика, так как не маппится нормально на разные языки программирования. Поэтому, всё же, ключи обычно — это строки без пробелов, и этот случай хочется сделать проще в написании.
Вопрос не в хорошей\плохой практике, а в спецификации.
Какую спецификацию вы имеете в виду?
Эту: An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs. A name is a string.
Только двойные кавычки, прошу отметить. Иначе — ни один парсер не пропустит.
Это формат удобочитаемый или для передачи данных по сети в большом объёме/с большой скоростью/быстрое сжатие? Потому что с первым проблем нет, а со вторым существующие решения не иделальны.
Смотря что подразумевается под большой скоростью и быстрым сжатием. Сам формат для больших структур с повторяющимися объектами должен быть сильно проще и короче, чем JSON (за счёт ссылок, например). Он по-прежнему текстовый, в этом смысле он будет похож на JSON (не как Protocol Buffers, например), и будет сжиматься как обычный текст (типы, например, в случае использования сжатия, почти исчезнут, так как они одинаковые).
Передача строк без кавычек бред. Каждый раз придется проверять на ключевые слова, раз. Два, это заряженый пистолет нацеленый в ногу. Рано или поздно вы просмотрите код запроса сами.
Вот это зачем? И как программа должна догадываться когда это использовать? И что делать парсеру если вы поменяли свойства местами?
Как ссылаться на объекты ниже, выше по иерерхии или в другой ветке?
Типы указывать вообще не нужно. Для всех данных есть модель которая их описывает. Если модели нет, то программе не с чем работать.
Посмотрите вот это.
object: { a: ..., b: ...}
object2(+object): { c: ..., d: ... }Вот это зачем? И как программа должна догадываться когда это использовать? И что делать парсеру если вы поменяли свойства местами?
property: value
another: @propertyКак ссылаться на объекты ниже, выше по иерерхии или в другой ветке?
Типы указывать вообще не нужно. Для всех данных есть модель которая их описывает. Если модели нет, то программе не с чем работать.
Посмотрите вот это.
Передача строк без кавычек бред.
Я так не считаю. Плюс, я не говорю, что кавычки не нужны, я говорю, что они обычно не нужны в именах пропертей.
И что делать парсеру если вы поменяли свойства местами?
Резолвить это, как и ссылки, после чтения файла.
Как ссылаться на объекты ниже, выше по иерерхии или в другой ветке?
Сейчас у меня ссылки идут от корня структуры, это решает все проблемы.
Типы указывать вообще не нужно. Для всех данных есть модель которая их описывает.
Это не всегда так, плюс, иногда бывает удобно саму модель строить по этому файлу (про это я выложу статью на днях). В этом случае типы — необходимая вещь. Если же есть модель, то типы можно не указывать, как и в JSON.
Я так не считаю. Плюс, я не говорю, что кавычки не нужны, я говорю, что они обычно не нужны в именах пропертей.
К названию свойств у меня нет притензий. Я про литерали строк ("Alex" => Alex).
Резолвить это, как и ссылки, после чтения файла.
Только вот зачем это? К тому-же что делать с коллизиями?
Сейчас у меня ссылки идут от корня структуры, это решает все проблемы.
Так себе решение.
Если уж хочется без свойств то лучше как-то так:
{
common#uniqueId: { ... },
object1: { prop: #uniqueId },
object2: { prop: #uniqueId }
}Это не всегда так, плюс, иногда бывает удобно саму модель строить по этому файлу (про это я выложу статью на днях). В этом случае типы — необходимая вещь. Если же есть модель, то типы можно не указывать, как и в JSON.
Если вы строите модель, по запросами которые пишите, у меня для вас плохие новости. Но даже если у вас в руках только одна сторона провода, вот вы сделали запрос и получили ответ:
{
data: (...)
}Во первых, как я узнаю тип корня? Во вторых, если было бы указано свойство data(Type), но у меня нету такого типа в проекте, как мне это поможет? Допустим я посмотрел запрос (нахрен такие апи) и по нему написал тип. Зачем мне теперь тип в ответе?
Допустим я получаю динамические данные в виде словаря:
// Плохой словарь
{
itemName1: { ... },
itemName2: { ... }
}
// Хороший словарь
[
{ key: "name1", value: { ... }, type: "Type1" },
{ key: "name2", value: { ... }, type: "Type2" }
]И тут мне не нужен тип.
Если уж хочется без свойств то лучше как-то так:
Да, использование ID — один из способов. Но их сложно поддерживать (это не важно при автогенерации, важно при ручном написании).
И тут мне не нужен тип.
Да, я просто предлагаю внутри формата поддержку такого рода данных (если требуется). Завтра я опубликую статью про S2, станет чуть понятнее, как именно удобно этим пользоваться.
Во первых, как я узнаю тип корня?...
Это не та задача, для которой введены (повторюсь, необязательные) типы.
Но и тут они могут помочь. Например, приходил объект с типом A, а потом кто-то на сервере решил, что нужен в этом месте тип Б. Принимающая сторона может проверить тип и выдать сообщение об ошибке, вместо попытки впихнуть объект Б внутрь А.
Зачем вы данные руками пишете?
А почему HTTP протокол текстовый?
Завтра будет статья про S2, там будет немного понятнее. Но вообще вопрос не совсем понятен. Что значит «зачем»? Иногда требуется для решения поставленной задачи. :)
http://jsonapi.org/ знаю. Проект правильный, будет здорово, если им (или аналогичным, не важно каким, на самом деле) будут пользоваться.
Почему не искаробочный plist?
Он далеко не всегда удобен. Плюс, его совсем неудобно генерировать на стороне сервера.
Уверен, для популярных веб-фреймворков найдется готовый плагин plist-сериализатора.
Это правда, но его неудобство не только в отсутствии плагинов. Это XML (или вообще бинарь), что усложняет чтение и запись, удлинняет (в случае текста) формат. Он крайне ограничен по типам, и, в отличие от базового XML — не допускает расширения. Даже вложенные объекты им не записать.
Я пробовал его использовать в разных ситуациях и обычно это оказывалось неудобно.
Я пробовал его использовать в разных ситуациях и обычно это оказывалось неудобно.
JSON — так себе формат для передачи данных между приложениями
Почему?
По стандарту [...] все названия должны заключаться в кавычки. Если мы используем JSON, например, для передачи данных по сети, то это излишество.
Почему это излишество? Это всего лишь более жесткое требование, упрощающее написание парсера.
Нет возможности пометить типами объекты, чтобы проще было модель понять.
А зачем аннотировать типы данных внутри формата передачи данных? Описывайте их в модели.
Отсутствие стандартов записи объектов.
Это банально неправда. JSON — и есть такой стандарт.
Это, например, может привести к массивам со смешанными объектами внутри.
Это позволяет массивы с разнотипными объектами. Это разве плохо?
Отсутствие ссылок.
Добавите ссылки — получите необходимость обработки циклов. Оно вам надо?
Это банально неправда. JSON — и есть такой стандарт.
Он описывает то, как объекты записываются в JavaScript'е. В других языках, обычно, они описываются совершенно иначе. JSON это не учитывает никак.
Я не рассматриваю использование KTV для JavaScript'а, нужно это сразу было отметить, моя ошибка.
Это позволяет массивы с разнотипными объектами. Это разве плохо?
Да.
Добавите ссылки — получите необходимость обработки циклов. Оно вам надо?
А без ссылок — структуры разрастаются, порой, в несколько раз. Но есть и достоинства в обоих решениях.
Он описывает то, как объекты записываются в JavaScript'е.
Уже давно нет.
В других языках, обычно, они описываются совершенно иначе.
А кого это волнует? Язык передачи данных не должен учитывать, как описываются объекты на любой стороне, он должен быть совместимым с этими сторонами.
Это позволяет массивы с разнотипными объектами. Это разве плохо?
Да.
Ну то есть возможность написать "у меня есть: корабль, машина, квартира и восемнадцать тонн бриллиантов" — это плохо?
А без ссылок — структуры разрастаются, порой, в несколько раз.
А как же компрессия, про которую вы же выше писали?
Уже давно нет.
:) В других языках в названиях полей класса допустимы пробелы? Отсутствуют типы кроме строк, чисел, булевого и null? Ой ли.
А кого это волнует? Язык передачи данных не должен учитывать, как описываются объекты на любой стороне, он должен быть совместимым с этими сторонами.
Ну, давайте вернемся к XML, он тоже всё описывает.
Ну то есть возможность написать «у меня есть: корабль, машина, квартира и восемнадцать тонн бриллиантов» — это плохо?
Абстрактно — хорошо. В реальности использовать такие структуры очень сложно.
А как же компрессия, про которую вы же выше писали?
Вы правы, при передаче данных это менее важно, зип такое сожмет отлично. Но есть и другие моменты.
При парсинге, в случае использования ссылок, можно использовать один и тот же объект в двух (двадцати) местах. Если же вы дублируете объекты в JSON'е, то и в памяти результирующие объекты будут разные. Это плохо.
В других языках в названиях полей класса допустимы пробелы?
В некоторых — да. Но, что важнее, то, как поля названы в передаваемой структуре, не обязано совпадать с тем, как поля названы на принимающей (или передающей) стороне. В некоторых языках, прямо скажем, и полей с классами может не быть, и что?
Отсутствуют типы кроме строк, чисел, булевого и null?
Важно, чтобы были строки, числа и далее по тексту. А то если пытаться охватить в нотации все возможные типы, вы никогда не закончите.
Ну, давайте вернемся к XML, он тоже всё описывает.
Во-первых, ваш логический скачок мне непонятен. XML как раз находится на другой стороне спектра — он очень сильно самодостаточен, в то время как JSON требует контекстной интерпретации.
Ну а во-вторых, XML, кроме избыточности и сложности парсинга ничем не плох, в нем как раз решается половина того, что вас не устраивает.
В реальности использовать такие структуры очень сложно.
Что сложного?
Если же вы дублируете объекты в JSON'е, то и в памяти результирующие объекты будут разные. Это плохо.
Смотря для чего. Ну и да, повторюсь, ссылки — это круто, но как только вы их добавляете, вы получаете необходимость подсчета циклов (а это само по себе мило) и придумывание правил для вывода этой красоты из исходного графа в дерево.
… Важно, чтобы были строки, числа и далее по тексту. А то если пытаться охватить в нотации все возможные типы, вы никогда не закончите.
Это правда. Но я и не пытаюсь это сделать.
Я завтра опубликую статью про S2, где будет понятно, зачем я составляю такую структуру.
Что сложного?
Сложность в интерпретации и контроле за такими объектами. В Swift (я пишу именно в контексте этого языка) строгая типизация, коллекции — однотипные. Такие структуры тяжело туда впихнуть.
Далее, сложность в использовании. Требуется обрабатывать массивы (мы сейчас про массивы, не про объекты, где типы у разных полей — разные) специальными средствами, простое итерирование не подходит. Нужно не забыть, что вдруг может попасться другой объект.
Также такое поведение иногда провоцирует на откровенно неправильные структуры, например, когда массивы используются вместо объектов (по первому индексу — ID, потом имя, потом фамилия...).
Я завтра опубликую статью про S2, где будет понятно, зачем я составляю такую структуру.
Ну то есть вы, на самом деле, пишете язык под конкретную задачу, но при этом вам не нравится JSON как формат передачи данных.
В Swift (я пишу именно в контексте этого языка) строгая типизация, коллекции — однотипные.
А я пишу на языках со строгой типизацией, где коллекции не однотипны (точнее, полиморфны). Зачем мне ваше искусственное ограничение?
Требуется обрабатывать массивы (мы сейчас про массивы, не про объекты, где типы у разных полей — разные) специальными средствами, простое итерирование не подходит.
Почему не подходит? Идете по коллекции итератором, дальше для каждого объекта принимаете решение. Вплоть до динамической диспетчеризации.
Ну то есть вы, на самом деле, пишете язык под конкретную задачу, но при этом вам не нравится JSON как формат передачи данных.
Я дополнил текст статьи. Как я уже сказал, я не рассматриваю KTV, как замену JSON. И не хочу, чтобы его использовали при работе с JavaScript'ом, это было бы глупо. Но я считаю, что JSON — не самый хороший вариант описания структур данных, в том числе и при их передаче.
Зачем мне ваше искусственное ограничение?
Видимо, вам оно не требуется. :-)
Почему не подходит?
Потому что в общем случае объекты в таком массиве могут быть любые. Динамическая диспетчеризация — это хорошо, но что, если с сервера в массиве начнет приходить тип, который не обрабатывается на клиенте? Появляется обработка ошибок, возможность сломаться в любой момент. Модель данных, наоборот, обычно старается зафиксировать формат передачи. А вы предлагаете его отпустить в свободное изменение и написать принимающей стороне хитрую динамическую логику. Не спорю, такие задачи тоже существуют, но их крайне мало и да, для таких задач JSON подойдёт лучше.
Но я считаю, что JSON — не самый хороший вариант описания структур данных, в том числе и при их передаче.
Но так и не указали на какой-нибудь "фундаментальный недостаток".
Динамическая диспетчеризация — это хорошо, но что, если с сервера в массиве начнет приходить тип, который не обрабатывается на клиенте?
А так будет рано или поздно, поэтому на эту ситуацию все равно надо заложиться.
Появляется обработка ошибок, возможность сломаться в любой момент.
А так вы обработку ошибок не пишете?
Модель данных, наоборот, обычно старается зафиксировать формат передачи.
И что делать, когда переданные данные не соответствуют этому формату?
А вы предлагаете его отпустить в свободное изменение и написать принимающей стороне хитрую динамическую логику.
Нет, не предлагаю. Я говорю, что бывают ситуации, когда это нужно, и лучше бы, если бы формат передачи это позволял.
Мне кажется, что нужно выбирать инструменты, исходя из задачи. Подходит больше JSON — используем JSON, подходит KTV — используем его.
У меня не было цели сделать универсальный формат для всего, поэтому не понимаю, с чем вы спорите. Да, он не подходит для всех задач, мне казалось, что я это чётко постулировал сам.
У меня не было цели сделать универсальный формат для всего, поэтому не понимаю, с чем вы спорите. Да, он не подходит для всех задач, мне казалось, что я это чётко постулировал сам.
TOML. Внизу страницы по ссылке список проектов его использующих и набор библиотек для разных языков.
Tree занятный, спасибо. И простой, это огромный плюс. Но мне хотелось чего-то ближе к привычному JSON'у.
Как бороться с развесистыми структурами — более-менее известно, KTV просто предлагает для этого способ, встроенный в формат.
Как бороться с развесистыми структурами — более-менее известно, KTV просто предлагает для этого способ, встроенный в формат.
Нет ничего ближе к привычному JSON, чем сам JSON. Реализовали бы KTV поверх JSON — сильно бы расширили число адептов и уменьшили сложность реализации.
Речь о том, что развесистые структуры не нужны вообще — только плоские списки фиксированной глубины. Их и дебажить проще, и в реализации они проще, и работают быстрее, и отдельного формата данных не требуют.
Речь о том, что развесистые структуры не нужны вообще — только плоские списки фиксированной глубины. Их и дебажить проще, и в реализации они проще, и работают быстрее, и отдельного формата данных не требуют.
Увы, реальность требует разных структур.
KTV — это надстройка над JSON, любой валидный JSON является валидным KTV. Если же зафиксировать какие-то правила JSON'а (как, например, предлагает http://jsonapi.org), то увеличится запись, мы немного приблизимся к XML по структуре (или даже к чему-то вроде XML-RPC), чего тоже хочется избежать.
KTV — это надстройка над JSON, любой валидный JSON является валидным KTV. Если же зафиксировать какие-то правила JSON'а (как, например, предлагает http://jsonapi.org), то увеличится запись, мы немного приблизимся к XML по структуре (или даже к чему-то вроде XML-RPC), чего тоже хочется избежать.
Например?
А что толку от того, что JSON можно распарсить KTV парсером? JSON парсер и так есть везде. Вот если бы KTV можно было распарсить JSON парсером — это было бы полезно. Так что стремление сделать похоже, но несовместимо — контрпродуктивно, и можно быть смелее в выборе синтаксиса, лучше оптимизировав его под решаемые задачи.
А что толку от того, что JSON можно распарсить KTV парсером? JSON парсер и так есть везде. Вот если бы KTV можно было распарсить JSON парсером — это было бы полезно. Так что стремление сделать похоже, но несовместимо — контрпродуктивно, и можно быть смелее в выборе синтаксиса, лучше оптимизировав его под решаемые задачи.
Есть ли бенчмарки скорости сериализации/десериализации в сравнении с JSON/YAML/Protobuf?
Посмотрите на MessagePack http://msgpack.org/ сильно быстрее и компактнее JSON. Хотя типы поддерживает тоже только самые простые.
Ага, спасибо. Про него знаю. Он хороший, но бинарный, мне нужен именно текстовый формат, завтра опубликую статью про S2, из неё будет немного яснее, зачем.
Лучше уж CBOR. Тоже бинарный, но это как-никак RFC, да и возможностей больше.
Советую с комментариями следать следующее
- Однострочные комментарии — в стиле си-подобных языков, начинаются с // и до конца строки
- Многострочные комментарии — также в стиле си-подобных языков, начинаются и заканчиваются также как в С/С++ с /* и заканчиваются */
- Блочные комментарии — начинаются с #, за которыми следует корректный блок кода (фигурно-скобочная группа { } ). Удобно, когда нужно отключить целый блок и не хочется ставить закрывающий многострочный комментарий, искать куда бы поставить */, а затем удалять его когда блок снова понадобится.
Вот тогда будет полный набор всех возможностей.
Третий вариант — очень интересен, спасибо. Не думаю, что буду его реализовывать (нет задачи сделать все-все-все), но как метод отладки структуры — супер!
4) Выкинуть комментарии вообще, ибо не нужны они в формате передачи данных. Оно не для того, чтобы его читать.
Формат требуется не только для передачи данных.
Ну расскажите нам тогда, зачем он ещё нужен.
Завтра опубликую про S2.
Документация. Для этих целей даже был придуман (найден) способ комментариев в самом json.
{
"title": "заголовок",
"title": "KTV. Новый JSON"
}:-) Не знал о таком. Смешной.
Стандарт явно говорит, что поведение парсера в этом случае не определено. Например, мой вариант
json_decode для Neovim превратит пример в {"_TYPE": v:msgpack_types.map, "_VAL": [["title", "заголовок"], ["title", "KTV. Новый JSON"]]}. RFC 7159:An object whose names are all unique is interoperable in the sense
that all software implementations receiving that object will agree on
the name-value mappings. When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
object, and some implementations report all of the name/value pairs,
including duplicates.
А json_decode из Vim покажет вам
Замечу, что мой парсер не просто выдаст такой прикольный словарь, но ещё и будет парсить пример два раза: один до того, как поймёт, что нужно использовать «специальный словарь», другой после: информация о порядке ключей на первом проходе не сохранялась, «особые случаи» намеренно не оптимизировались из‐за их предположительной редкости. Разумеется, это дело сопровождается двойным выделением памяти и дополнительным освобождением.
E721: Duplicate key in Dictionary: "title".Замечу, что мой парсер не просто выдаст такой прикольный словарь, но ещё и будет парсить пример два раза: один до того, как поймёт, что нужно использовать «специальный словарь», другой после: информация о порядке ключей на первом проходе не сохранялась, «особые случаи» намеренно не оптимизировались из‐за их предположительной редкости. Разумеется, это дело сопровождается двойным выделением памяти и дополнительным освобождением.
Зачем хранить документацию в JSON?
Для хранения данных. Различные конфигурационные/настроечные файлы например. JSON и подобные ему форматы это не только web, если что.
Мне нравится, когда текст в одну строчку
*_* {name(string): Alexcoolness(double): 3.1415isAProgrammer(bool): true}
UFO just landed and posted this here
ссылки убивают любые поточные процессоры. Плохо.
А что, если всё же разделить человекопонятные форматы для данных и конфигурации, и форматы машинного обмена данными? В таком случае, не потребуется долго и мучительно искать замену JSON, в которой будет больше типов/меньше кавычек. У нас, например, JSON используется, если нужно получить человекочитаемые данные, а для машинного обмена — CBOR. Сервер определяет, какой формат отдать на основе заголовка Accept. Выигрыш в скорости разбора почти в два раза по процессору и немного по памяти (не нужно буферизовать строку, если встречен '\'). Выигрыша в объёме данных около 5%.
P.S. Оба декодировщика — потоковые на основе std::basic_stream. Позволяет начать разбирать данные ещё до их полного получения.
P.S. Оба декодировщика — потоковые на основе std::basic_stream. Позволяет начать разбирать данные ещё до их полного получения.
Плюсы и минусы JSONСправедливости ради, в спецификации JSON Schema они таки есть.
Отсутствие ссылок
Это — формат описания объектов в JavaScript'еПо забавному совпадению, JSON-документ с некоторыми купюрами (null/None) является валидным описанием dict в Python. Кстати, именно поэтому ваше ограничение на тип объектов в массиве выглядит надуманным, в питоне, как и в JS, можно класть объекты разного типа в массив.
Если нужно прямо сэкономить на трафике, возьмите protocol buffers ;) Если нет, то есть JSON и YAML, которые по крайней мере везде поддерживаются из коробки
Ради коллекции, упомяну свой велосипед: JSON с комментариями (jsonComm). Сделан на JS, не слишком трудно сделать на других языках, но скорости KTV (из-за кавычек и структуры) не достигнет.
Ну и для конфигов кроме вышеупомянутого toml ещё порекомендую HOCON
Ни в коем случае не хочу сказать, что JSON идеален, и всегда для всего подходит. Таких стандартов и форматов просто не бывает. Но конкретно описанные вами проблемы — исключительно проблемы плохого кода.
Вы серьёзно? Вы правда считаете, что 0.5% оптимизации объёма чего-то стоят? Может, тогда стоит сэкономить в языках разработки на пробелах, табуляции и точках с запятой, чтобы экономить диск программиста?
Типизация указана в модели, которая используется вашим генератором и потребителем. Если типы одинаковые, то сериализируются и десериализируются они одинаково. И совершенно непонятно, зачем вам "понимать" JSON. Разве что если вам привезли тележку неизвестного JSON и сказали его познавать. Но это какая-то странная ситуация.
А вы это вручную парсите? Не надо так! У меня даже на Arduino стоит библиотека для создания и разборки JSON. И если у вас корректная модель, то никакой боли не возникает.
Не надо ничего придумывать, в случае повторяющихся объектов надо использовать идентификаторы объектов, которые заменят вам любые ссылки. Всё придумано давно и очень очевидно.
Про комментарии в стандарте для передачи данных даже говорить не буду — и так очевидно.
Зато вы придумали свой стандарт. И если вам придётся работать с кем-то ещё, или другими сервисами — вас все проклянут — никому не хочется разбираться с самописным стандартом.
Кавычки. По стандарту (в качестве стандарта я беру текст отсюда: www.json.org) все названия должны заключаться в кавычки. Если мы используем JSON, например, для передачи данных по сети, то это излишество.
Вы серьёзно? Вы правда считаете, что 0.5% оптимизации объёма чего-то стоят? Может, тогда стоит сэкономить в языках разработки на пробелах, табуляции и точках с запятой, чтобы экономить диск программиста?
Отсутствие типизации. Точнее, типы есть, но всего строка/число/true/false/null. И объекты с массивами. Всё. Ни дат, ни целых/дробных чисел нет. Нет возможности пометить типами объекты, чтобы проще было модель понять.
Типизация указана в модели, которая используется вашим генератором и потребителем. Если типы одинаковые, то сериализируются и десериализируются они одинаково. И совершенно непонятно, зачем вам "понимать" JSON. Разве что если вам привезли тележку неизвестного JSON и сказали его познавать. Но это какая-то странная ситуация.
Отсутствие стандартов записи объектов. Это, например, может привести к массивам со смешанными объектами внутри. Когда приходится такое парсить — становится больно.
А вы это вручную парсите? Не надо так! У меня даже на Arduino стоит библиотека для создания и разборки JSON. И если у вас корректная модель, то никакой боли не возникает.
Отсутствие ссылок. Если в JSON записывать иерархическую структуру объектов, то регулярно встречаются ссылки на один и тот же объект из разных мест. JSON не даёт возможности сослаться на первое использование. Нужно либо что-то придумывать, либо повторять объекты целиком, что плохо сказывается на размере структуры и на сложности парсинга.
Не надо ничего придумывать, в случае повторяющихся объектов надо использовать идентификаторы объектов, которые заменят вам любые ссылки. Всё придумано давно и очень очевидно.
Про комментарии в стандарте для передачи данных даже говорить не буду — и так очевидно.
Зато вы придумали свой стандарт. И если вам придётся работать с кем-то ещё, или другими сервисами — вас все проклянут — никому не хочется разбираться с самописным стандартом.
Вы правы.
Но, кроме указанных вами кейсов, существуют и другие, в которых решения, которые я применяю — более выгодны, чем применяемые вами. Для этого и существует множество форматов, которые используются в разных ситуациях.
Но вы правы, всё перечисленное мной можно реализовать в JSON. Впрочем, и в простом тексте можно, и в XML, и в ещё многих-многих вариантах.
Но, кроме указанных вами кейсов, существуют и другие, в которых решения, которые я применяю — более выгодны, чем применяемые вами. Для этого и существует множество форматов, которые используются в разных ситуациях.
Но вы правы, всё перечисленное мной можно реализовать в JSON. Впрочем, и в простом тексте можно, и в XML, и в ещё многих-многих вариантах.
Да, жду вашу публикацию про S2 — очень интересно посмотреть, какой будет кейс под такое решение. Возможно, лучше было бы объединить публикации — или выкатить одновременно — тогда было бы понятнее, зачем вам такой формат.
Первая часть тут: https://habrahabr.ru/post/278787/
Сейчас немного обкатаю код на Swift и через какое-то время выложу вторую часть, вместе со ссылкой на библиотеки и исходный код.
Сейчас немного обкатаю код на Swift и через какое-то время выложу вторую часть, вместе со ссылкой на библиотеки и исходный код.
Sign up to leave a comment.
KTV. Новый JSON