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

@joe.lane 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

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.

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

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?

it complicates it :)

😆 but not helpful!

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.

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.

true

I’ve had a few conversations with RH about this

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

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

seems like there should be a good way to leverage that

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

but that doesn’t really address the access difference

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?

meh

Hahaha 🙂 I suspected that might be your response!

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

it’s pretty ugly when munged

user=> (munge "x/y")
"x_SLASH_y"

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

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