KC
По крайней мере без добавления конвенций
Size: a a a
2020 November 13
AP
экспортер тоже можем написать мы
AP
будет reference
KC
экспортер тоже можем написать мы
В json все равно не получится выразить хэши где ключами может быть все что угодно кроме строк
KC
Например edn
KC
Да что edn даже xml не получится выразить без потери информации или без добавления логики в ридер/врайтер
AP
Я как раз хочу, чтобы ключами были только safe chars! Кому надо, сделает список пар
AP
Т.е. задача основная — передавать records, а не "маппинги всего во всё".
AP
Терпеть кавычки вокруг каждого ключа только для того, чтобы поиметь возможность иметь в ключах пробелы, не хочется. А всех возможных ключей всё равно не предусмотреть. Может кто захочет рекорды в роли ключей иметь? Это слишком усложняет формат
AP
Кароч, я за атомы/киворды в роли ключей.
KC
Терпеть кавычки вокруг каждого ключа только для того, чтобы поиметь возможность иметь в ключах пробелы, не хочется. А всех возможных ключей всё равно не предусмотреть. Может кто захочет рекорды в роли ключей иметь? Это слишком усложняет формат
Ну так посмотри на edn. Имхо единственный действительно расширяемый и компактный формат
AP
Блин. Только лишь сегодня за утро я лично слово EDN употребил раз восемь
AP
EDN не умеет в байтстроки без кодирования в неэкономичные форматы
KC
Умеет через инструкции ридера
AP
Нужно парсеру сказать, что сейчас пойдут байтики такой-то длины, а не структура
KC
Так не умеет, дп
AP
А значит придётся либо base64 делать, либо ещё как-то извращаться
AP
EDN подходит для литералов — опции указывать для программ в командной строке, выводить в pretty printed форме
AP
Вообще всё зависит от того, насколько глубоко упарываться. Если идти по пути "всё есть один формат, который можно интроспектить" то и блобов будет минимум. А небольшие порции можно и в base64 хранить