Завтра будет статья про S2, там будет немного понятнее. Но вообще вопрос не совсем понятен. Что значит «зачем»? Иногда требуется для решения поставленной задачи. :)
Третий вариант — очень интересен, спасибо. Не думаю, что буду его реализовывать (нет задачи сделать все-все-все), но как метод отладки структуры — супер!
Мне кажется, что нужно выбирать инструменты, исходя из задачи. Подходит больше JSON — используем JSON, подходит KTV — используем его.
У меня не было цели сделать универсальный формат для всего, поэтому не понимаю, с чем вы спорите. Да, он не подходит для всех задач, мне казалось, что я это чётко постулировал сам.
Ага, спасибо. Про него знаю. Он хороший, но бинарный, мне нужен именно текстовый формат, завтра опубликую статью про S2, из неё будет немного яснее, зачем.
KTV — это надстройка над JSON, любой валидный JSON является валидным KTV. Если же зафиксировать какие-то правила JSON'а (как, например, предлагает http://jsonapi.org), то увеличится запись, мы немного приблизимся к XML по структуре (или даже к чему-то вроде XML-RPC), чего тоже хочется избежать.
Ну то есть вы, на самом деле, пишете язык под конкретную задачу, но при этом вам не нравится JSON как формат передачи данных.
Я дополнил текст статьи. Как я уже сказал, я не рассматриваю KTV, как замену JSON. И не хочу, чтобы его использовали при работе с JavaScript'ом, это было бы глупо. Но я считаю, что JSON — не самый хороший вариант описания структур данных, в том числе и при их передаче.
Зачем мне ваше искусственное ограничение?
Видимо, вам оно не требуется. :-)
Почему не подходит?
Потому что в общем случае объекты в таком массиве могут быть любые. Динамическая диспетчеризация — это хорошо, но что, если с сервера в массиве начнет приходить тип, который не обрабатывается на клиенте? Появляется обработка ошибок, возможность сломаться в любой момент. Модель данных, наоборот, обычно старается зафиксировать формат передачи. А вы предлагаете его отпустить в свободное изменение и написать принимающей стороне хитрую динамическую логику. Не спорю, такие задачи тоже существуют, но их крайне мало и да, для таких задач JSON подойдёт лучше.
Да, использование ID — один из способов. Но их сложно поддерживать (это не важно при автогенерации, важно при ручном написании).
И тут мне не нужен тип.
Да, я просто предлагаю внутри формата поддержку такого рода данных (если требуется). Завтра я опубликую статью про S2, станет чуть понятнее, как именно удобно этим пользоваться.
Во первых, как я узнаю тип корня?...
Это не та задача, для которой введены (повторюсь, необязательные) типы.
Но и тут они могут помочь. Например, приходил объект с типом A, а потом кто-то на сервере решил, что нужен в этом месте тип Б. Принимающая сторона может проверить тип и выдать сообщение об ошибке, вместо попытки впихнуть объект Б внутрь А.
… Важно, чтобы были строки, числа и далее по тексту. А то если пытаться охватить в нотации все возможные типы, вы никогда не закончите.
Это правда. Но я и не пытаюсь это сделать.
Я завтра опубликую статью про S2, где будет понятно, зачем я составляю такую структуру.
Что сложного?
Сложность в интерпретации и контроле за такими объектами. В Swift (я пишу именно в контексте этого языка) строгая типизация, коллекции — однотипные. Такие структуры тяжело туда впихнуть.
Далее, сложность в использовании. Требуется обрабатывать массивы (мы сейчас про массивы, не про объекты, где типы у разных полей — разные) специальными средствами, простое итерирование не подходит. Нужно не забыть, что вдруг может попасться другой объект.
Также такое поведение иногда провоцирует на откровенно неправильные структуры, например, когда массивы используются вместо объектов (по первому индексу — ID, потом имя, потом фамилия...).
Это правда, но его неудобство не только в отсутствии плагинов. Это XML (или вообще бинарь), что усложняет чтение и запись, удлинняет (в случае текста) формат. Он крайне ограничен по типам, и, в отличие от базового XML — не допускает расширения. Даже вложенные объекты им не записать.
Я пробовал его использовать в разных ситуациях и обычно это оказывалось неудобно.
Нет, на отступы рассчитывать не планируется.
До сотни на мероприятие.
У меня не было цели сделать универсальный формат для всего, поэтому не понимаю, с чем вы спорите. Да, он не подходит для всех задач, мне казалось, что я это чётко постулировал сам.
И это замечательно.
Самый простой пример — когда у вас нет контроля за самим форматом. Приходится работать с тем, что есть.
Это совершенно верно.
(Впрочем, когда был распространен XML, также говорили про сам JSON)
KTV — это надстройка над JSON, любой валидный JSON является валидным KTV. Если же зафиксировать какие-то правила JSON'а (как, например, предлагает http://jsonapi.org), то увеличится запись, мы немного приблизимся к XML по структуре (или даже к чему-то вроде XML-RPC), чего тоже хочется избежать.
По ощущениям, парсинг должен быть примерно, как JSON по скорости.
Я дополнил текст статьи. Как я уже сказал, я не рассматриваю KTV, как замену JSON. И не хочу, чтобы его использовали при работе с JavaScript'ом, это было бы глупо. Но я считаю, что JSON — не самый хороший вариант описания структур данных, в том числе и при их передаче.
Видимо, вам оно не требуется. :-)
Потому что в общем случае объекты в таком массиве могут быть любые. Динамическая диспетчеризация — это хорошо, но что, если с сервера в массиве начнет приходить тип, который не обрабатывается на клиенте? Появляется обработка ошибок, возможность сломаться в любой момент. Модель данных, наоборот, обычно старается зафиксировать формат передачи. А вы предлагаете его отпустить в свободное изменение и написать принимающей стороне хитрую динамическую логику. Не спорю, такие задачи тоже существуют, но их крайне мало и да, для таких задач JSON подойдёт лучше.
Да, использование ID — один из способов. Но их сложно поддерживать (это не важно при автогенерации, важно при ручном написании).
Да, я просто предлагаю внутри формата поддержку такого рода данных (если требуется). Завтра я опубликую статью про S2, станет чуть понятнее, как именно удобно этим пользоваться.
Это не та задача, для которой введены (повторюсь, необязательные) типы.
Но и тут они могут помочь. Например, приходил объект с типом A, а потом кто-то на сервере решил, что нужен в этом месте тип Б. Принимающая сторона может проверить тип и выдать сообщение об ошибке, вместо попытки впихнуть объект Б внутрь А.
Как бороться с развесистыми структурами — более-менее известно, KTV просто предлагает для этого способ, встроенный в формат.
Это правда. Но я и не пытаюсь это сделать.
Я завтра опубликую статью про S2, где будет понятно, зачем я составляю такую структуру.
Сложность в интерпретации и контроле за такими объектами. В Swift (я пишу именно в контексте этого языка) строгая типизация, коллекции — однотипные. Такие структуры тяжело туда впихнуть.
Далее, сложность в использовании. Требуется обрабатывать массивы (мы сейчас про массивы, не про объекты, где типы у разных полей — разные) специальными средствами, простое итерирование не подходит. Нужно не забыть, что вдруг может попасться другой объект.
Также такое поведение иногда провоцирует на откровенно неправильные структуры, например, когда массивы используются вместо объектов (по первому индексу — ID, потом имя, потом фамилия...).
Я пробовал его использовать в разных ситуациях и обычно это оказывалось неудобно.