Clojurians Log v2
beginners
Hi everyone 👋 What is the use case for qualified keywords ? According to https://github.com/nufuturo-ufcg/clj-smells-catalog?tab=readme-ov-file#namespaced-keys-neglect it's bad, but it doesn't say how. If I look at this https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj it looks to me like unqualified keywords are used everywhere. Do you think it's a code smell ? I don't, but maybe there is something I don't know here..
This is a frequently asked question. See https://ask.clojure.org/index.php/10380/when-to-use-simple-qualified-keywords
That code smells repo was written for non-Clojure languages and ported to Clojure (as far as I know, without any experienced Clojurians involved). Most of it isn't exactly wrong but I would view it with significant skepticism.
I disagree with this supposed code smell specifically. Namespaced keywords are great but unqualified keywords are perfectly reasonable in a lot of scenarios.
Qualified keywords shine when they will travel far within a Clojure system, and when there are a lot of keywords competing in the same semantic space. In contexts where the keyword will mostly stay within a particular namespace (or a small handful), or if it's fairly unique, using a namespace feels far less necessary.
The benefit of keywords is that they're self-describing. Sometimes they don't need a namespace to do that. Sometimes a namespace really helps.
thank you both! I'll keep on preferring unqualified then 🙂 and consider it when it competes with other keywords.
for example so that their :id doesn't replace or misrepresent my :id (or vice versa) I'd use my-namespace/:id in that scenario.
I'll give a concrete example of where qualified keywords are important: next.jdbc -- if you do a SQL JOIN across two tables, say person and address, that both have a primary key column called id, you want to be able to tell them apart in the result. That's why, by default, next.jdbc returns result sets where the keys are of the form :table/column, so you'd get :person/id and :address/id.
tysm for the guidance and swift responses 🐎
From what I see you can spec string keys in malli. Is there some inbuilt support for that in spec too? I'd like to avoid keywordizing keys from a JSON object I'm consuming, as I'm wary of any edge cases in the string -> keyword -> string conversion.
Not easily without keywordizing
How much control do you have over the json key space ?
None in this case. But thanks, I just wanted to check if I'm missing something obvious before deciding on the way to go about this.
I'm having a bit of trouble using java-http-clj to create a websocket server, probably because I'm misunderstanding something fundamental. I think, as I look at the example code, that what I'm creating there is a client, but what should the code look like for the server? Do I need another library?
The code I'm looking at is here: https://github.com/schmee/java-http-clj?tab=readme-ov-file#websockets
Not familiar with the library but this would be my guess: https://github.com/schmee/java-http-clj/blob/master/src/java_http_clj/websocket.clj#L35-L66
And I think these are the relevant javadocs for the interop this library is wrapping: https://docs.oracle.com/en/java/javase/22/docs/api/java.net.http/java/net/http/WebSocket.Listener.html
It looks like syntax is that it takes a single map as an argument with on-binary on-close on-error on-open on-ping on-pong on-text as keys you can pass in for as functions for how to handle various input types
Fantastic, thank you. And then if I'm experimenting with this on my own computer, I just spin them up on two separate ports and they can talk to each other. I'll see how far this takes me and come back if I get lost!
you said "create a websocket server" but the linked code looks like a client library