@bealex8 мар 2016 в 09:01

KTV. Новый JSON

6 мин

17K

Разработка мобильных приложений * iOS *

111

Комментарии 111

@k12th 8 мар 2016 в 09:07

Оо, в этом месяце еще не было джейсона без кавычек и с комментариями.

@bealex 8 мар 2016 в 09:14

Велосипеды — это наше всё!

@bealex 8 мар 2016 в 17:01

Не знаете, как бы их найти тут? Я бы почитал про другие попытки, интересно.

@kafeman 8 мар 2016 в 20:02

«Свой 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/

@bealex 8 мар 2016 в 20:14

Спасибо за ссылки!

@extempl 9 мар 2016 в 08:43

Всё-таки есть и обратная сторона — вы, как и я, заинтересовались заголовком и тизером и зашли почитать. Вопрос — чего мы с вами ожидали от статьи? Лулзов? А может, всё-таки, надеемся что кто-то таки придумал более удобный формат? Если второе, то я думаю, попытки имеют право быть — почему нет?

@grossws 9 мар 2016 в 10:17

Я, например, зашел посмотреть на проблему, которая привела к попытке создания своего формата. Если говорить про сериализацию, то ничего принципиально интересного в дополнительной типизации полей я не вижу, т. к. это усложняет десериализатор, но не даёт гарантий, что пришедший объект валиден (например, могут нарушаться какие-нибудь инварианты).

Ну и ради лулзов, ессно.

@mayorovp 9 мар 2016 в 15:05

+: https://habrahabr.ru/post/224261/

@kafeman 9 мар 2016 в 15:09

Да их еще несколько десятков тут найти можно.

@mayorovp 9 мар 2016 в 16:40

Да, но там я заинтересованное лицо :)

@rayz_razko 8 мар 2016 в 09:11

Автор пишет об излишестве кавычек (что ошибочно, ибо JSON позволяет в качестве ключа использовать {'i am a key': 'value'}), но в то же время хочет добавлять типы. Странно как-то.

@bealex 8 мар 2016 в 09:14

Кавычки в KTV допустимы, как раз для таких случаев.

@rayz_razko 8 мар 2016 в 09:19

Если мы используем JSON, например, для передачи данных по сети, то это излишество.

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

@bealex 8 мар 2016 в 09:25

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

Ещё строки не способствуют строгой типизации. Внутри JSON'а — часто объекты, объекты, которые парсятся в строго-типизированные языки. Строки маппить в строготипизированный язык тяжело (посмотрите, сколько парсеров JSON'а существует). Мне кажется, что если зажать этот формат несколько сильнее, то его проще будет редактировать, проще контролировать и работать с ним. Не в любом контексте, а в том, который я указываю.

@rayz_razko 8 мар 2016 в 09:30

Если JSON объект парсится в строго типизированном языке, то, скорее всего, существует контракт(модель). Т.е. принимающая сторона ожидает, что в проперти "name" будет лежать строка, а в проперти "age" целочисленный тип данных.

@bealex 8 мар 2016 в 09:38

Это правда, но часто модель приходится делать уже по существующим JSON'ам (которые делались для сайта, например), поэтому изначально контракты отсутствовали, что приводит к очень, очень сложным моделям для парсинга. Как я отметил в статье, например, разные типы кладутся в коллекции или названия полей недопустимы для целевого языка.

Опять же, ссылки на объекты часто бывают полезны.

@rayz_razko 8 мар 2016 в 09:42

то приводит к очень, очень сложным моделям для парсинга

Это уже проблема не JSON-а

@bealex 8 мар 2016 в 09:46

Конечно, это моя проблема, как разработчика. Про это я и говорю.

@esc 8 мар 2016 в 14:54

А чем поможет ваш формат, если типы все равно не будут указаны (они ж не обязательны) ?

@bealex 8 мар 2016 в 15:04

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

@zagayevskiy 8 мар 2016 в 15:27

А потом вы будете искать баги в своём парсере? Более короткий JSON? Зачем?

@bealex 8 мар 2016 в 09:16

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

@rayz_razko 8 мар 2016 в 09:20

Вопрос не в хорошей\плохой практике, а в спецификации.

@bealex 8 мар 2016 в 09:25

Какую спецификацию вы имеете в виду?

@rayz_razko 8 мар 2016 в 09:39

Эту: An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs. A name is a string.

@bealex 8 мар 2016 в 09:46

А как эта спецификация относится к новому формату? :-)

@rayz_razko 8 мар 2016 в 09:55

Вы утверждали, что кавычки излишни, я же возразил что это не так. При чем это было написано "между прочим". Суть комментария была совершенно другая.

@bealex 8 мар 2016 в 10:04

:) Ок, понял.

@Carduelis 8 мар 2016 в 11:32

Только двойные кавычки, прошу отметить. Иначе — ни один парсер не пропустит.

@ainu 8 мар 2016 в 09:31

Это формат удобочитаемый или для передачи данных по сети в большом объёме/с большой скоростью/быстрое сжатие? Потому что с первым проблем нет, а со вторым существующие решения не иделальны.

@bealex 8 мар 2016 в 09:45

Смотря что подразумевается под большой скоростью и быстрым сжатием. Сам формат для больших структур с повторяющимися объектами должен быть сильно проще и короче, чем JSON (за счёт ссылок, например). Он по-прежнему текстовый, в этом смысле он будет похож на JSON (не как Protocol Buffers, например), и будет сжиматься как обычный текст (типы, например, в случае использования сжатия, почти исчезнут, так как они одинаковые).

@Sannis 11 мар 2016 в 00:36

Ничто не мешает использовать protobuf для описания формата и при этом сериализовывать данные в JSON.

@bealex 11 мар 2016 в 06:37

Ммм. Занятный вариант, не думал пока про такое. Спасибо за идею!

@aikixd 8 мар 2016 в 09:56

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

object: { a: ..., b: ...}
object2(+object): { c: ..., d: ... }

Вот это зачем? И как программа должна догадываться когда это использовать? И что делать парсеру если вы поменяли свойства местами?

property: value
another: @property

Как ссылаться на объекты ниже, выше по иерерхии или в другой ветке?

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

Посмотрите вот это.

@bealex 8 мар 2016 в 10:08

Передача строк без кавычек бред.

Я так не считаю. Плюс, я не говорю, что кавычки не нужны, я говорю, что они обычно не нужны в именах пропертей.

И что делать парсеру если вы поменяли свойства местами?

Резолвить это, как и ссылки, после чтения файла.

Как ссылаться на объекты ниже, выше по иерерхии или в другой ветке?

Сейчас у меня ссылки идут от корня структуры, это решает все проблемы.

Типы указывать вообще не нужно. Для всех данных есть модель которая их описывает.

Это не всегда так, плюс, иногда бывает удобно саму модель строить по этому файлу (про это я выложу статью на днях). В этом случае типы — необходимая вещь. Если же есть модель, то типы можно не указывать, как и в JSON.

@aikixd 8 мар 2016 в 10:41

Я так не считаю. Плюс, я не говорю, что кавычки не нужны, я говорю, что они обычно не нужны в именах пропертей.

К названию свойств у меня нет притензий. Я про литерали строк ("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" }
]

И тут мне не нужен тип.

@bealex 8 мар 2016 в 10:48

Если уж хочется без свойств то лучше как-то так:

Да, использование ID — один из способов. Но их сложно поддерживать (это не важно при автогенерации, важно при ручном написании).

И тут мне не нужен тип.

Да, я просто предлагаю внутри формата поддержку такого рода данных (если требуется). Завтра я опубликую статью про S2, станет чуть понятнее, как именно удобно этим пользоваться.

Во первых, как я узнаю тип корня?...

Это не та задача, для которой введены (повторюсь, необязательные) типы.

Но и тут они могут помочь. Например, приходил объект с типом A, а потом кто-то на сервере решил, что нужен в этом месте тип Б. Принимающая сторона может проверить тип и выдать сообщение об ошибке, вместо попытки впихнуть объект Б внутрь А.

@zagayevskiy 8 мар 2016 в 13:23

Зачем вы данные руками пишете?

@vintage 8 мар 2016 в 13:32

А почему HTTP протокол текстовый?

@zagayevskiy 8 мар 2016 в 15:31

Ну, наверное, потому, что в те времена, когда его придумывали, о контенте в сети думали как о гипертексте (hypertext transfer protocol). Ну, и с тех пор появилось мнение о том, что это неправильно. HTTP 2 — бинарный. А вы зачем спрашиваете? Тоже JSON руками пишете?

@vintage 8 мар 2016 в 17:38

Будь HTTP изначально бинарным, то страницы мы сейчас открывали бы не по HTTPS, а по SFTP ;-) Сложное это дело, заниматься отладкой по бинарному протоколу.

@bealex 8 мар 2016 в 13:33

Завтра будет статья про S2, там будет немного понятнее. Но вообще вопрос не совсем понятен. Что значит «зачем»? Иногда требуется для решения поставленной задачи. :)

@zagayevskiy 8 мар 2016 в 15:33

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

@bealex 8 мар 2016 в 15:49

:) Я старался не акцентировать внимание исключительно на передаче данных. Если вдруг где-то пропустил, покажите, пожалуйста. Передача данных — важная, но не единственная задача, решаемая такого рода форматами.

@bealex 8 мар 2016 в 10:29

http://jsonapi.org/ знаю. Проект правильный, будет здорово, если им (или аналогичным, не важно каким, на самом деле) будут пользоваться.

@corristo 8 мар 2016 в 09:56

Почему не искаробочный plist?

@bealex 8 мар 2016 в 10:08

Он далеко не всегда удобен. Плюс, его совсем неудобно генерировать на стороне сервера.

@corristo 8 мар 2016 в 10:09

Уверен, для популярных веб-фреймворков найдется готовый плагин plist-сериализатора.

@bealex 8 мар 2016 в 10:31

Это правда, но его неудобство не только в отсутствии плагинов. Это XML (или вообще бинарь), что усложняет чтение и запись, удлинняет (в случае текста) формат. Он крайне ограничен по типам, и, в отличие от базового XML — не допускает расширения. Даже вложенные объекты им не записать.

Я пробовал его использовать в разных ситуациях и обычно это оказывалось неудобно.

@lair 8 мар 2016 в 09:58

JSON — так себе формат для передачи данных между приложениями

Почему?

По стандарту [...] все названия должны заключаться в кавычки. Если мы используем JSON, например, для передачи данных по сети, то это излишество.

Почему это излишество? Это всего лишь более жесткое требование, упрощающее написание парсера.

Нет возможности пометить типами объекты, чтобы проще было модель понять.

А зачем аннотировать типы данных внутри формата передачи данных? Описывайте их в модели.

Отсутствие стандартов записи объектов.

Это банально неправда. JSON — и есть такой стандарт.

Это, например, может привести к массивам со смешанными объектами внутри.

Это позволяет массивы с разнотипными объектами. Это разве плохо?

Отсутствие ссылок.

Добавите ссылки — получите необходимость обработки циклов. Оно вам надо?

@bealex 8 мар 2016 в 10:11

Это банально неправда. JSON — и есть такой стандарт.

Он описывает то, как объекты записываются в JavaScript'е. В других языках, обычно, они описываются совершенно иначе. JSON это не учитывает никак.

Я не рассматриваю использование KTV для JavaScript'а, нужно это сразу было отметить, моя ошибка.

Это позволяет массивы с разнотипными объектами. Это разве плохо?

Да.

Добавите ссылки — получите необходимость обработки циклов. Оно вам надо?

А без ссылок — структуры разрастаются, порой, в несколько раз. Но есть и достоинства в обоих решениях.

@lair 8 мар 2016 в 10:14

Он описывает то, как объекты записываются в JavaScript'е.

Уже давно нет.

В других языках, обычно, они описываются совершенно иначе.

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

Это позволяет массивы с разнотипными объектами. Это разве плохо?

Да.
Ну то есть возможность написать "у меня есть: корабль, машина, квартира и восемнадцать тонн бриллиантов" — это плохо?

А без ссылок — структуры разрастаются, порой, в несколько раз.

А как же компрессия, про которую вы же выше писали?

@bealex 8 мар 2016 в 10:21

Уже давно нет.

:) В других языках в названиях полей класса допустимы пробелы? Отсутствуют типы кроме строк, чисел, булевого и null? Ой ли.

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

Ну, давайте вернемся к XML, он тоже всё описывает.

Ну то есть возможность написать «у меня есть: корабль, машина, квартира и восемнадцать тонн бриллиантов» — это плохо?

Абстрактно — хорошо. В реальности использовать такие структуры очень сложно.

А как же компрессия, про которую вы же выше писали?

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

При парсинге, в случае использования ссылок, можно использовать один и тот же объект в двух (двадцати) местах. Если же вы дублируете объекты в JSON'е, то и в памяти результирующие объекты будут разные. Это плохо.

@lair 8 мар 2016 в 10:28

В других языках в названиях полей класса допустимы пробелы?

В некоторых — да. Но, что важнее, то, как поля названы в передаваемой структуре, не обязано совпадать с тем, как поля названы на принимающей (или передающей) стороне. В некоторых языках, прямо скажем, и полей с классами может не быть, и что?

Отсутствуют типы кроме строк, чисел, булевого и null?

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

Ну, давайте вернемся к XML, он тоже всё описывает.

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

Ну а во-вторых, XML, кроме избыточности и сложности парсинга ничем не плох, в нем как раз решается половина того, что вас не устраивает.

В реальности использовать такие структуры очень сложно.

Что сложного?

Если же вы дублируете объекты в JSON'е, то и в памяти результирующие объекты будут разные. Это плохо.

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

@bealex 8 мар 2016 в 10:36

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

Это правда. Но я и не пытаюсь это сделать.

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

Что сложного?

Сложность в интерпретации и контроле за такими объектами. В Swift (я пишу именно в контексте этого языка) строгая типизация, коллекции — однотипные. Такие структуры тяжело туда впихнуть.

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

Также такое поведение иногда провоцирует на откровенно неправильные структуры, например, когда массивы используются вместо объектов (по первому индексу — ID, потом имя, потом фамилия...).

@lair 8 мар 2016 в 10:46

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

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

В Swift (я пишу именно в контексте этого языка) строгая типизация, коллекции — однотипные.

А я пишу на языках со строгой типизацией, где коллекции не однотипны (точнее, полиморфны). Зачем мне ваше искусственное ограничение?

Требуется обрабатывать массивы (мы сейчас про массивы, не про объекты, где типы у разных полей — разные) специальными средствами, простое итерирование не подходит.

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

@bealex 8 мар 2016 в 10:52

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

Я дополнил текст статьи. Как я уже сказал, я не рассматриваю KTV, как замену JSON. И не хочу, чтобы его использовали при работе с JavaScript'ом, это было бы глупо. Но я считаю, что JSON — не самый хороший вариант описания структур данных, в том числе и при их передаче.

Зачем мне ваше искусственное ограничение?

Видимо, вам оно не требуется. :-)

Почему не подходит?

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

@lair 8 мар 2016 в 11:39

Но я считаю, что JSON — не самый хороший вариант описания структур данных, в том числе и при их передаче.

Но так и не указали на какой-нибудь "фундаментальный недостаток".

Динамическая диспетчеризация — это хорошо, но что, если с сервера в массиве начнет приходить тип, который не обрабатывается на клиенте?

А так будет рано или поздно, поэтому на эту ситуацию все равно надо заложиться.

Появляется обработка ошибок, возможность сломаться в любой момент.

А так вы обработку ошибок не пишете?

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

И что делать, когда переданные данные не соответствуют этому формату?

А вы предлагаете его отпустить в свободное изменение и написать принимающей стороне хитрую динамическую логику.

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

@bealex 8 мар 2016 в 12:05

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

У меня не было цели сделать универсальный формат для всего, поэтому не понимаю, с чем вы спорите. Да, он не подходит для всех задач, мне казалось, что я это чётко постулировал сам.

@lair 8 мар 2016 в 12:26

поэтому не понимаю, с чем вы спорите

Я спорю с тезисом "JSON — так себе формат для передачи данных между приложениями".

@bealex 8 мар 2016 в 12:33

Ага, понял.

@gearbox 8 мар 2016 в 10:06

TOML. Внизу страницы по ссылке список проектов его использующих и набор библиотек для разных языков.

@bealex 8 мар 2016 в 10:13

Класс, спасибо, очень интересно. Мне хотелось быть ближе к привычному JSON'у, но формат очень интересный.

@vintage 8 мар 2016 в 10:33

Формат Tree.
Как бороться с развесистыми структурами.

@bealex 8 мар 2016 в 10:39

Tree занятный, спасибо. И простой, это огромный плюс. Но мне хотелось чего-то ближе к привычному JSON'у.

Как бороться с развесистыми структурами — более-менее известно, KTV просто предлагает для этого способ, встроенный в формат.

@vintage 8 мар 2016 в 10:49

Нет ничего ближе к привычному JSON, чем сам JSON. Реализовали бы KTV поверх JSON — сильно бы расширили число адептов и уменьшили сложность реализации.

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

@bealex 8 мар 2016 в 10:58

Увы, реальность требует разных структур.

KTV — это надстройка над JSON, любой валидный JSON является валидным KTV. Если же зафиксировать какие-то правила JSON'а (как, например, предлагает http://jsonapi.org), то увеличится запись, мы немного приблизимся к XML по структуре (или даже к чему-то вроде XML-RPC), чего тоже хочется избежать.

@vintage 8 мар 2016 в 11:07

Например?

А что толку от того, что JSON можно распарсить KTV парсером? JSON парсер и так есть везде. Вот если бы KTV можно было распарсить JSON парсером — это было бы полезно. Так что стремление сделать похоже, но несовместимо — контрпродуктивно, и можно быть смелее в выборе синтаксиса, лучше оптимизировав его под решаемые задачи.

@bealex 8 мар 2016 в 11:10

Например?

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

JSON парсер и так есть везде.

Это совершенно верно.

(Впрочем, когда был распространен XML, также говорили про сам JSON)

@vintage 8 мар 2016 в 11:32

Изобретение своего формата тут мало чем поможет.

При этом JSON не стали делать совместимым с XML.

@bealex 8 мар 2016 в 11:37

При этом JSON не стали делать совместимым с XML.

И это замечательно.

@trueClearThinker 8 мар 2016 в 10:46

Есть ли бенчмарки скорости сериализации/десериализации в сравнении с JSON/YAML/Protobuf?

@bealex 8 мар 2016 в 10:54

Пока нет. Мне интересно пока, на правильном ли я пути.

По ощущениям, парсинг должен быть примерно, как JSON по скорости.

@mgyk 8 мар 2016 в 11:14

Посмотрите на MessagePack http://msgpack.org/ сильно быстрее и компактнее JSON. Хотя типы поддерживает тоже только самые простые.

@bealex 8 мар 2016 в 11:19

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

@GamePad64 8 мар 2016 в 13:45

Лучше уж CBOR. Тоже бинарный, но это как-никак RFC, да и возможностей больше.

@NeoCode 8 мар 2016 в 11:47

Советую с комментариями следать следующее

Однострочные комментарии — в стиле си-подобных языков, начинаются с // и до конца строки
Многострочные комментарии — также в стиле си-подобных языков, начинаются и заканчиваются также как в С/С++ с /* и заканчиваются */
Блочные комментарии — начинаются с #, за которыми следует корректный блок кода (фигурно-скобочная группа { } ). Удобно, когда нужно отключить целый блок и не хочется ставить закрывающий многострочный комментарий, искать куда бы поставить */, а затем удалять его когда блок снова понадобится.
Вот тогда будет полный набор всех возможностей.

@bealex 8 мар 2016 в 12:07

Третий вариант — очень интересен, спасибо. Не думаю, что буду его реализовывать (нет задачи сделать все-все-все), но как метод отладки структуры — супер!

@zagayevskiy 8 мар 2016 в 13:31

4) Выкинуть комментарии вообще, ибо не нужны они в формате передачи данных. Оно не для того, чтобы его читать.

@bealex 8 мар 2016 в 13:33

Формат требуется не только для передачи данных.

@zagayevskiy 8 мар 2016 в 15:34

Ну расскажите нам тогда, зачем он ещё нужен.

@bealex 8 мар 2016 в 15:49

Завтра опубликую про S2.

@ZurgInq 8 мар 2016 в 16:56

Документация. Для этих целей даже был придуман (найден) способ комментариев в самом json.

{
  "title": "заголовок",
  "title": "KTV. Новый JSON"
}

@bealex 8 мар 2016 в 17:00

:-) Не знал о таком. Смешной.

@ZyXI 8 мар 2016 в 19:15

Стандарт явно говорит, что поведение парсера в этом случае не определено. Например, мой вариант 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.

@ZyXI 8 мар 2016 в 19:23

А json_decode из Vim покажет вам E721: Duplicate key in Dictionary: "title".

Замечу, что мой парсер не просто выдаст такой прикольный словарь, но ещё и будет парсить пример два раза: один до того, как поймёт, что нужно использовать «специальный словарь», другой после: информация о порядке ключей на первом проходе не сохранялась, «особые случаи» намеренно не оптимизировались из‐за их предположительной редкости. Разумеется, это дело сопровождается двойным выделением памяти и дополнительным освобождением.

@zagayevskiy 8 мар 2016 в 19:10

Зачем хранить документацию в JSON?

@ZurgInq 8 мар 2016 в 19:31

Наоборот. В документации хранится образец в виде json. Да хоть swagger документация тому пример. Только там комментарии в json не используется, т.к.это всё таки трюк.

@NeoCode 9 мар 2016 в 07:40

Для хранения данных. Различные конфигурационные/настроечные файлы например. JSON и подобные ему форматы это не только web, если что.

@lampa 8 мар 2016 в 14:14

Мне нравится, когда текст в одну строчку *_*

{name(string): Alexcoolness(double): 3.1415isAProgrammer(bool): true}

@bealex 8 мар 2016 в 14:41

Можно разделять запятой или точкой с запятой, если в одну строчку

@lampa 8 мар 2016 в 14:43

а если в тексте эти символы есть, их экранировать или как?

@bealex 8 мар 2016 в 14:43

Текст в этом случае нужно заключить в кавычки. Экран стандартный: «\», после него символ считается частью строки.

@lampa 8 мар 2016 в 14:47

Я еще очень надеюсь, что вы не добавите вместо кавычек отступы. Прям как в jade. А так задумка вполне нравится)

@bealex 8 мар 2016 в 15:03

Спасибо!

Нет, на отступы рассчитывать не планируется.

НЛО прилетело и опубликовало эту надпись здесь

@bealex 8 мар 2016 в 15:46

Всё так.

Я соберу отзывы, после чего напишу грамматику языка.

@amarao 8 мар 2016 в 15:39

ссылки убивают любые поточные процессоры. Плохо.

@bealex 8 мар 2016 в 15:47

Это правда. Но JSON и так обычно парсится в ассоциативный массив, целиком. В редких случаях, когда нужна поточная обработка — можно ссылки запретить (или вообще не использовать KTV).

@SBKarr 8 мар 2016 в 15:49

А что, если всё же разделить человекопонятные форматы для данных и конфигурации, и форматы машинного обмена данными? В таком случае, не потребуется долго и мучительно искать замену JSON, в которой будет больше типов/меньше кавычек. У нас, например, JSON используется, если нужно получить человекочитаемые данные, а для машинного обмена — CBOR. Сервер определяет, какой формат отдать на основе заголовка Accept. Выигрыш в скорости разбора почти в два раза по процессору и немного по памяти (не нужно буферизовать строку, если встречен '\'). Выигрыша в объёме данных около 5%.

P.S. Оба декодировщика — потоковые на основе std::basic_stream. Позволяет начать разбирать данные ещё до их полного получения.

@bealex 8 мар 2016 в 15:53

Хорошее решение. Но такое редко необходимо, требует существенно больше поддержки на всех платформах, которые взаимодействуют.

С другой стороны, вы используете, например, JSON, а не XML. Почему? Потому что JSON удобнее. Мне кажется, что KTV будет ещё удобнее.

@prefrontalCortex 8 мар 2016 в 18:16

Плюсы и минусы JSON
Отсутствие ссылок

Справедливости ради, в спецификации JSON Schema они таки есть.

Это — формат описания объектов в JavaScript'е

По забавному совпадению, JSON-документ с некоторыми купюрами (null/None) является валидным описанием dict в Python. Кстати, именно поэтому ваше ограничение на тип объектов в массиве выглядит надуманным, в питоне, как и в JS, можно класть объекты разного типа в массив.

@bealex 8 мар 2016 в 18:25

Ссылки несложно ввести, при необходимости, я так делал в ÅSS.

… можно класть объекты разного типа в массив

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

@loststylus 9 мар 2016 в 11:25

Если нужно прямо сэкономить на трафике, возьмите protocol buffers ;) Если нет, то есть JSON и YAML, которые по крайней мере везде поддерживаются из коробки

@spmbt 9 мар 2016 в 14:38

Ради коллекции, упомяну свой велосипед: JSON с комментариями (jsonComm). Сделан на JS, не слишком трудно сделать на других языках, но скорости KTV (из-за кавычек и структуры) не достигнет.

@bealex 9 мар 2016 в 16:17

Ага, спасибо, погляжу.

@grossws 9 мар 2016 в 16:23

Ну и для конфигов кроме вышеупомянутого toml ещё порекомендую HOCON

@jehy 10 мар 2016 в 08:06

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

Кавычки. По стандарту (в качестве стандарта я беру текст отсюда: www.json.org) все названия должны заключаться в кавычки. Если мы используем JSON, например, для передачи данных по сети, то это излишество.

Вы серьёзно? Вы правда считаете, что 0.5% оптимизации объёма чего-то стоят? Может, тогда стоит сэкономить в языках разработки на пробелах, табуляции и точках с запятой, чтобы экономить диск программиста?

Отсутствие типизации. Точнее, типы есть, но всего строка/число/true/false/null. И объекты с массивами. Всё. Ни дат, ни целых/дробных чисел нет. Нет возможности пометить типами объекты, чтобы проще было модель понять.

Типизация указана в модели, которая используется вашим генератором и потребителем. Если типы одинаковые, то сериализируются и десериализируются они одинаково. И совершенно непонятно, зачем вам "понимать" JSON. Разве что если вам привезли тележку неизвестного JSON и сказали его познавать. Но это какая-то странная ситуация.

Отсутствие стандартов записи объектов. Это, например, может привести к массивам со смешанными объектами внутри. Когда приходится такое парсить — становится больно.

А вы это вручную парсите? Не надо так! У меня даже на Arduino стоит библиотека для создания и разборки JSON. И если у вас корректная модель, то никакой боли не возникает.

Отсутствие ссылок. Если в JSON записывать иерархическую структуру объектов, то регулярно встречаются ссылки на один и тот же объект из разных мест. JSON не даёт возможности сослаться на первое использование. Нужно либо что-то придумывать, либо повторять объекты целиком, что плохо сказывается на размере структуры и на сложности парсинга.

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

Про комментарии в стандарте для передачи данных даже говорить не буду — и так очевидно.

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

@bealex 10 мар 2016 в 08:43

Вы правы.

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

Но вы правы, всё перечисленное мной можно реализовать в JSON. Впрочем, и в простом тексте можно, и в XML, и в ещё многих-многих вариантах.

@jehy 10 мар 2016 в 08:49

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

@bealex 10 мар 2016 в 08:52

Первая часть тут: https://habrahabr.ru/post/278787/

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий