Clojurians Log v2

@brownmoose3q привет, а будут ли новые выпуски? Клёвые видео, ты не бросай это дело 🙏

Господа, а у меня одного любой подход к спеке заканчивается "ох, никак с её помощью толком не повалидировать внешние данные"?

И есть ли, чем валидировать внешние данные и приводить их в приличный вид?

А то у меня какая-нибудь хреновина типа {"type": "add_something", "id": "<uuid>", "pos": 17, "entry": {"id": 4, ...}} приезжает, и надо её разбирать.

Спекой неудобно. Спекой хорошо {:change/type :add-something :change/id #uuid "..." :change/pos 17 :change/entry {:entry/id 4 ...}} проверять.

неужели совсем неудобно?

Во-первых, спека не умеет мапы со строковыми ключами.

Во-вторых, во входящих данных разные типы значений под одинаковыми ключами (см. id).

мапу можно рассматривать как последовательность

В-третьих, всё равно надо коэрсить.

В-четвёртых, что, писать две спеки: на внешний формат, и на починеный?

@akond И как, удобно последовательность спекать "в этой последовательности обязательно иметь вектор с первым элементом "type", обязательно иметь вектор с первым элементом "pos" и обязательно иметь вектор с первым элементом "entry""?

(s/and vector? (s/cat :k (partial = "test") :v number?))

Мне нужна "антиспека": сделанная для закрытого мира, и с предположением, что всё входящее надо трансформировать.

тогда зачем вторая спека?

Вторая для поддержки инвариантов внутри системы.

Т.е. первая "вот здесь будут ключи, их все на этом уровне превратить в ключевые слова по этому алгоритму, другие все ключи - ошибка". Вторая (s/keys :req [:change/type :change/id :change/pos])

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

Спасибо, кэп!

> И есть ли, чем валидировать внешние данные и приводить их в приличный вид?

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

Но раз ничего нет, то значит руками.

автоматизирвать в смысле показать ей пример, а она тебе готовую спеку?

В смысле, не писать баланду "проверить, что в этой мапе ключи строки, и там есть такие-то", а DSL а-ля спека, только наоборот.

Спека живёт в открытом мире, антиспека - в закрытом.

Спека считает коэрсии отклонением, антиспека – нормой.

Спека считает, что ключи уникально идентифицируют сущности, антиспека считает, что "id" во входящем документе будет 17 раз в трёх разных синтаксисах.

Наверное, этого уже достаточно, чтобы 1) сначала сделать разбор внешних данных руками; 2) посмотреть на этот разбор и сделать из него библиотеку и DSL.

Нужно раздобыть гамак.

можно добавить в спеку условие :else и туда все будет валиться, если я правильно понял что ты хочешь

Вот тебе паззл: покрой спекой JSON-чик выше. На первом уровне ключ "id" — UUID, на втором — int64.

а жсон разве поддерживатье 64 битовые целые?

в JSON числа произвольной длины, если что.

В любом случае, производители и потребители этого JSON – Swift и Go, так что проблемы языков без int64 их не волнуют.

а, это в жс ограничение

{"type" "add_something", "id" uuid?, "pos" 17, "entry" {"id" 4}} вот так?

ключи обязательные или нет?

Все ключи обязательные.

`(s/explain (s/cat :first (s/and vector? (s/cat :k (partial = "type") :v string?)) :second (s/and vector? (s/cat :k2 (partial = "id") :v2 uuid?)) :third (s/and vector? (s/cat :k3 (partial = "pos") :v3 number?)) :entry (s/and vector? (s/cat :k4 (partial = "entry") :v4 some?)) ) {"type" "add_something", "id" (java.util.UUID/randomUUID), "pos" 17, "entry" {"id" 4}})`

uuid? матчит строку?

Ключи могут идти в любом порядке, это же JSON.

не, это для примера

Да, можно отсортировать, но таких мап у меня, допустим 50, и они вложенные. Всех сортировать?

И теперь результат хочется привести к виду "Спекой хорошо ... проверять", сколько это ещё будет кода?

Да, и ещё :v4 непоспекан. Тоже (s/cat)?

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

Поэтому и нужен DSL.

на v4 своя спека должна быть

s/* скорее всего

ты хотел что-то в виде bison?

типа EBNF

вот еще забавная штука: https://github.com/stathissideris/spec-provider

@akond Я хотел бы что-то в виде спеки, но со всеми решениями наоборот 🙂

Бизон - это ж просто EBNF. Зачем EBNF на уже разобранном дереве?

по аналогии я имею в виду

хотя спека и так оно и есть

и чего это тебе по воскресеньям спекой решилось заниматься?

"решения наоборот" - абстракция, которую я плохо (вообще не) понимаю

@dottedmag даже если ты извратишься и опишешь то что тебе надо спекой, оно будет как минимум нечитаемое

schema гораздо лучше подходит для валидации внешних данных, но насчет коерсии я не уверен

ребята с Аттендифая вот довели идею схемы до refined types https://github.com/KitApps/schema-refined

а, есть у schema коерсия

вобщем, я б schema попробовал

@fmnoise Вот, очень интересно, спасибо.