question regarding preference: do you add your specs to an existing namespace of a domain model or do you have a separate spec namespace to share your specs around?
@johnjelinek Here's how we organize the different types of specs we write https://corfield.org/blog/2019/09/13/using-spec/
Oh, sorry, I added threading in the message for readability, actual spec doesn't have it
Thanks, I'll try that
so, how safe is it to use s/conform
as a regex matcher?
As in https://juxt.pro/blog/parsing-with-clojure-spec
(s/def ::contentline
(s/cat
:name ::iana-token
:params (s/*
(s/cat
:semi #{\;}
:param-name ::iana-token
:equals #{\=}
:param-value ::iana-token))
:colon #{\:}
:value ::iana-token))
(s/conform
::contentline
(seq "DTSTART;TZID=US-EAST:20180116T140000"))
=>
{:name [\D \T \S \T \A \R \T],
:params
[{:semi \;,
:param-name [\T \Z \I \D],
:equals \=,
:param-value [\U \S \- \E \A \S \T]}],
:colon \:,
:value [\2 \0 \1 \8 \0 \1 \1 \6 \T \1 \4 \0 \0 \0 \0]}
(apply str (get-in ā¦ [:params 0 :param-value]))
=> "US-EAST"
Thinking about using it to parse recurrence rule from RFC5545 https://icalendar.org/iCalendar-RFC-5545/3-3-10-recurrence-rule.html
spec isn't designed for string parsing -- I've seen people recommend instaparse: (alex miller on the topic) https://www.reddit.com/r/Clojure/comments/fx5ko1/parser_libraries/fmttmzy/?utm_source=amp&utm_medium=
Thanks @uwo!
I think Iām not that interested in performance here, more interested in how stable the implementation will be.
we do not recommend using regex specs to parse strings