Fork me on GitHub
Joe Lane18:02:18

If the above snippet is OT and belongs somewhere else, I’ll gladly take it there instead.


@lanejo01 Would it work to just remove the namespace from the keys in args? e.g. (into {} (map (fn [[k v]] [(keyword (name k)) v])) {:foo/bar 1 :foo/baz 2}) ;; => {:bar 1, :baz 2}


If you didn’t want to remove the namespace from all keys, you could pass in a specific prefix to remove in this case, :myapp.entity.user

Joe Lane20:02:02

Interesting, yeah I could do that to just keep the unqualified keys. Im wondering if i’m missing some design step though since from the jira ticket it was concluded that there wasn’t planned work for namespaced keys in records.

Alex Miller (Clojure team)21:02:28

I didn’t read everything above, but have you tried using s/keys with :req-un to spec records

Joe Lane22:02:33

Ahh, I think thats the answer @alexmiller. I had read through that section of the spec guide probably 15 times last night but it didn’t click. This also pushes me away from desiring namespaced keywords in records. Thank you!


@alexmiller On that subject... given the general advice re: maps / records is usually "use maps, and only switch to records if you need extra performance", how does that sit with using namespaced maps -- since those cannot easily be switched to records?


😆 but not helpful!

Alex Miller (Clojure team)22:02:03

I mean if you have maps with namespaced keys, you can switch to records and change specs from :req to :req-un


Fair enough. The spread of namespaced maps does seem to reduce the attraction of using records further.

Alex Miller (Clojure team)22:02:38

unfortunately, I agree. I seem to be in the minority, but I like records. :)


@alexmiller Yeah, but all of your code that manipulates those maps would need to change too -- since it will be using :foo/bar now and would need to change to :bar.

Alex Miller (Clojure team)22:02:18

I’ve had a few conversations with RH about this


I'll be interested to hear what he decides in the end 🙂

Alex Miller (Clojure team)22:02:52

records actually do have a namespace context via the package of the defining record type

Alex Miller (Clojure team)22:02:05

seems like there should be a good way to leverage that

Alex Miller (Clojure team)22:02:40

like field a in record my.R could use spec :my/a if req’ed in a s/keys

Alex Miller (Clojure team)22:02:01

but that doesn’t really address the access difference

Alex Miller (Clojure team)22:02:19

would also need to allow lookup by ns’ed key in the record, which maybe would be interesting


Perhaps an option on defrecord to produce either plain keys or namespaced keys? I assume the / could be munged to something Java would accept?


Hahaha 🙂 I suspected that might be your response!

Alex Miller (Clojure team)22:02:54

I think adding new access mechanisms is greatly preferable to adding options


it’s pretty ugly when munged

user=> (munge "x/y")

Alex Miller (Clojure team)22:02:12

optional behavior flags either means you’re being lazy or haven’t thought about it long enough :)

Alex Miller (Clojure team)22:02:13

probably better to improve how a record spec would link fields to attribute specs in a way that supports more kinds of code evolution