so is anyone else constantly doing this: (s/keys ::req-un [::key-a ::key-b])? with all the namespaced keywords I usually don't even notice what is wrong

and keep wondering why my spec doesn't work, any chance this could throw a warning?

@thheller http://dev.clojure.org/jira/browse/CLJ-2112 should help

doesn't look like it would catch this case as ::req-un would just be ignored again

Is there a spec for date?

inst?

Thanks @souenzzo. What about a date that is stored as a string?

string?

I’d like the spec to validate “03/27/2016” but not “Hello World"

There are date time parsers in the Java std lib

Either that or a regex pred

(I was just joking about string? :)

OK

user=> (import 'java.text.SimpleDateFormat)
java.text.SimpleDateFormat
user=> (def formatter (SimpleDateFormat. "MM/dd/yyyy"))
#'user/formatter
user=> (.parse formatter "03/27/2016")
#inst “2016-03-27T05:00:00.000-00:00”

you’d want to wrap up the call to .parse to catch ParseException and return false

cool

thx a lot

(defn valid-date? [s] (try (.parse formatter s) (catch ParseException e false)))

this is not threadsafe tho

truth

usually you wrap that in a ThreadLocal

I had a weird debugging session because of this a few years back

yes or just use joda.time (or possibly new java api)

good point - I haven’t used much of the new java 8 stuff

you’d want to use java.time.format.DateTimeFormatter

(import [java.time.format DateTimeFormatter DateTimeParseException] java.time.LocalDate)
(def format (DateTimeFormatter/ofPattern “MM/dd/yyyy"))
(defn valid-date? [s] (try (LocalDate/parse s format) (catch DateTimeParseException _ false)))

that should be thread-safe

please burn the prior example

@mpenet what did u mean by not thread-safe?

maybe the formatter isn't thread safe?

what does it mean for a fomatter not to be thread-safe?

multiple threads using the same formatter is not safe

since formatter is a class instance and stores intermediate parse data in instance variables

yes if you call .parse from multiple threads you'll get garbage back sometimes

it gets quite obvious (date very much in the future etc etc)

Unbelievable!

it seemed like a good idea in the 90's

No, it really didnt

hi please can you help me?? how I can make a spec case insensitive:

(s/def :vtex/channel #{"KUSHKIPAGOS"})

you could replace the spec with #(= (clojure.string/upper-case %) "KUSHKIPAGOS")

on the topic of accidental double colon on ::req-un - that’s a situtation where the parameters are plainly provided statically, so MAAAAYBE warning on unrecognized keys wouldn’t be totally objectionable - but that would require trusting ppl to not abuse whatever flag enables that check

i mentioned this before, see https://www.typescriptlang.org/docs/handbook/interfaces.html and search for “excess property checking"

might be possible to accomplish with metadata or something - if the object has file/line/column info, then it might be a candidate for excess property checking

just a thought