PP
"Все дороги ведут в Рим", похоже что вот этот issue вызвал больше всего дискуссий об этом:
https://github.com/ptaoussanis/sente/issues/251
https://github.com/ptaoussanis/sente/issues/251
Size: a a a
2020 December 10
PP
В основном советуют использовать Transit вместо edn.
PP
Но вообще вся эта история как-то не в духе Рича что ли. 😟 На первый взгляд штука вроде простая, а так коварно заминирована.
(Всё, у меня стадия принятия, спасибо!)
(Всё, у меня стадия принятия, спасибо!)
T
Но вообще вся эта история как-то не в духе Рича что ли. 😟 На первый взгляд штука вроде простая, а так коварно заминирована.
(Всё, у меня стадия принятия, спасибо!)
(Всё, у меня стадия принятия, спасибо!)
Ну. Помоему оно не то что бы коварно. Оно просто "вот так". Пожалуйста))
PP
Очень коварно. Когда начинаешь осваивать, кажется что это "one format to rule them all" (в контексте Clojure во всяком случае). А потом оказывается и что Clojure на самом деле его НАДмножество; и что Clojure с лёгкостью выдаёт непредставимые в нём значения казалось бы поддерживаемых типов (ради перформанса, ок, но строгий вариант где-нибудь есть?)...
2020 December 11
DF
вот прицепились! нафига вам пробелы в keyword'ах?
давайте ещё наругаем числа с пробелами между группами из 3 разрядов.
123 456 789 - это три числа или одно?
давайте ещё наругаем числа с пробелами между группами из 3 разрядов.
123 456 789 - это три числа или одно?
T
вот прицепились! нафига вам пробелы в keyword'ах?
давайте ещё наругаем числа с пробелами между группами из 3 разрядов.
123 456 789 - это три числа или одно?
давайте ещё наругаем числа с пробелами между группами из 3 разрядов.
123 456 789 - это три числа или одно?
Три числа. Кложура мне не выплюнет из коробки такую штуку. А киворды с пробелами часто получаются из keywordize-keys
https://clojuredocs.org/clojure.walk/keywordize-keys
https://clojuredocs.org/clojure.walk/keywordize-keys
DF
когда у тебя в данных ключи с пробелами, то можно же не делать keywordize-keys. Зачем? Тока не говори про быстродействие, ПЛЗ.
T
когда у тебя в данных ключи с пробелами, то можно же не делать keywordize-keys. Зачем? Тока не говори про быстродействие, ПЛЗ.
Он автоматически накидывается на приходящие жсоны
T
Откуда эти жсоны, когда, как и в каком коде будут использоваться это вне моего контроля. Просто все жсоны читаются с keywordize keys
T
#:"extended keyword"
Вот такой синтаксис прикольно было бы иметь, кстатиОн клешится с занеймспейшенной хешмапой правда
Можно обойтись и
#kw"extended keyword"
или#keyword"extended keyword"
Теперь надо добавить ридер и остается задача заоверрайдить clojure.lang.Keyword.toString() Но это страшные костыли
VG
#:"extended keyword"
Вот такой синтаксис прикольно было бы иметь, кстатиОн клешится с занеймспейшенной хешмапой правда
Можно обойтись и
#kw"extended keyword"
или#keyword"extended keyword"
Теперь надо добавить ридер и остается задача заоверрайдить clojure.lang.Keyword.toString() Но это страшные костыли
#keyword “with sp” наравне с #inst “2020-12-10T22:00:00”T
#keyword “with sp” наравне с #inst “2020-12-10T22:00:00”Ну да кстати. Чего бы нет
VG
но с другой стороны, если тебе прилетают неподконтрольные джейсоны, то, вероятно стоит пойти в подконтрольный тебе код и убрать keywordize-keys 🙂
DF
но с другой стороны, если тебе прилетают неподконтрольные джейсоны, то, вероятно стоит пойти в подконтрольный тебе код и убрать keywordize-keys 🙂
да. я тоже это хотел сказать.
DF
а то получается, что ты ругаешься на кложурный keyword работая не с edn а с json'ами. ну извини.
T
но с другой стороны, если тебе прилетают неподконтрольные джейсоны, то, вероятно стоит пойти в подконтрольный тебе код и убрать keywordize-keys 🙂
Сыглы, но кейвордайз кейс делает зависимость моей зависимости. И весь проект уже полагается на то что там киворды, я не могу это ни заманкипатчить, ни отрефакторить
DF
I'm so sorry!
T
Но если че, это не проблема. Я просто передаю это как джсон, а не едн, тк исходные данные как раз и были джсоном, на который и наложен кейвордайз
T
Я изначально просто интересовался кто как с такой проблемой справляется