Fork me on GitHub

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

šŸ‘ 3
Ivan Fedorov15:10:37

so, how safe is it to use s/conform as a regex matcher? As in

(s/def ::contentline
    :name ::iana-token
    :params (s/*
                :semi #{\;}
                :param-name ::iana-token
                :equals #{\=}
                :param-value ::iana-token))
    :colon #{\:}
    :value ::iana-token))

  (seq "DTSTART;TZID=US-EAST:20180116T140000"))
{:name [\D \T \S \T \A \R \T],
 [{: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"


spec isn't designed for string parsing -- I've seen people recommend instaparse: (alex miller on the topic);utm_medium=

Ivan Fedorov16:10:00

I think Iā€™m not that interested in performance here, more interested in how stable the implementation will be.

metal 3
Ivan Fedorov15:10:24

Thinking about using it to parse recurrence rule from RFC5545

Alex Miller (Clojure team)17:10:37

we do not recommend using regex specs to parse strings

šŸ‘ 3