@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?))
я проверял мапу как последовательность mapentry, поэтому нам вектор
Мне нужна "антиспека": сделанная для закрытого мира, и с предположением, что всё входящее надо трансформировать.
тогда зачем вторая спека?
Вторая для поддержки инвариантов внутри системы.
Т.е. первая "вот здесь будут ключи, их все на этом уровне превратить в ключевые слова по этому алгоритму, другие все ключи - ошибка". Вторая (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)
?
если без порядка, то (s/* (s/alt
. выкрутиться можно. другое дело что много текста.
Получится больше текста, чем вручную то же самое писать.
Поэтому и нужен 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 Вот, очень интересно, спасибо.