Closed bsless closed 1 year ago
@ikitommi I believe the MR is ready for review. I tried to cover everything I could think of, lmk if there are some gaps
Regarding the split and the addition of a bunch of namespaces, we have a few options, which I'm not a big fan of:
load
like clojure.core doesSerialization:
#time/date "2020-01-01"
(separate library?)timex
:
No problem, will clean up a bit then make the change.
Edit: question, change the ns fragment to timex
too, or just the keyword namespace?
Thoughts?
I must say that after s/:time\//:timex\//g
it just looks silly. It's just not aesthetic
1.ii
- I think all the docs needed is how to add the time-schemas into registry using the malli.experimental.time
namespace?:timex
, agree, kinda like :rolex
🤣. would :jvm/date-time
be better? if not, any suggestions how to handle this?serialization, I was thinking just about values, but the schema serialization is another issue. When there is JS/CLJS supported version, support for data + parser would be good. I think we can start with the current way you proposed it.
regarding timex, my suggestion is to just use time
Rationale - these map to the ISO-8601 formatters: https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
If anything, the prefix could be iso
or iso-time
. Barring that, just time
seems most correct. It's a universal standard we're trying to satisfy
I agree :time
is correct in the long run. My idea was just that we could use something else in case the schemas change (types, names, properties, formats) before CLJS/JS impl is done. Otherwise, there can be a silent breakage causing hard-to-debug problems if someone has persisted the schemas into db. With new schema name, one needs to migrate the schemas.
That said, current Temporal model doesn't seem that different:
I'm merging this now, we can post-tune this before release.
Big thanks for the PR!!
Awesome! I'll prepare a docs update
About the easy includes. Maybe something like:
(ns malli.experimental.time.module
(:require [malli.experimental.time]
[malli.experimental.time.generator]
[malli.experimental.time.json-schema]
[malli.experimental.time.transform]))
(defn schemas []
(malli.experimental.time/-time-schemas))
... IMO sucks, but maybe less than the alternatives.
What about moving it to conditional read as part of malli.core?
that would make this non-experimental. We can do that later.
Would have wanted something like Emacs's advice or eval-after-load mechanism
Can we put it in core and gate its evaluation behind a jvm property or dynamic variable?, sort of eval-when
?
Let's not do that yet. We can merge the time-schemas into the core namespaces when we drop the experimental
ns part after proper test-run in projects & design verification on CLJS side. Most (if not all) the projects I've done (and seen) with malli have a custom registry already so it's easy to mount in the new time schemas.
btw, I'm still on holiday this week and mostly not reading emails, so lag in responding.
Please find below an initial implementation for time schemas
Status: mature draft, at testing phase Scope: JVM, schemas, transformers, generators, JSON schema, swagger
Design:
At various points users can provide a DateTimeFormatter or pattern which will be compiled to one.