Clojurians Log v2

(defmacro uh-oh []
  (let [id (gensym "id")
        m {:id id}]
   m))

(uh-oh)
;; Syntax error compiling at (*cider-repl Code/flex:localhost:50966(clj)*:35:7).
;; Unable to resolve symbol: id20798 in this context

ah I unqoute then quote it

(defmacro uh-oh []
  (let [id (gensym "id")
        m {:id id}]
   `'~m))

(uh-oh)
;; => {:id id20812}

ah but that prevents eval of any of m:

(defmacro uh-oh
  [f]
  (let [id (gensym "id")
        m {:id id :f f}]
   `'~m))

(uh-oh (fn [] "foo"))
;; => {:id id20820, :f (fn [] "foo")}

(defmacro uh-oh []
  (let [id (gensym "id")
        m {:id (list 'quote id)}]
   m))

aha! thank you

(defmacro foo [] {:id 'id#})`

the backquote is there before the map but it's quite confused the parser

see above why backqouting the whole map doesn't quite work

oh i see

Is there any guidance on when one should use simple/qualified keywords?

for example {:my.company/errors [:timeout vs :my.company/timeout]}

Or even (s/keys :req [::foo]) :req being simple

My rules of thumb: 1. qualified keywords for extension mechanisms, so that you can register your own stuff under your own namespace and avoid conflicts 2. simple keywords for internal implementation details The argument against qualified keywords is mostly brevity.

I'd love to see seasoned Clojurians like @alexmiller and @seancorfield reply. Ideally, I believe this should be addressed in a rationale on http://clojure.org.

Perhaps here:

Yeah, I was searching for something like that at first

perhaps this is something for ask clojure

IMHO the higher the probability of name clashing, the more reasons there are to use namespaces. In a controlled environment, like the confines of my own project, I almost exclusively use plain keywords. It also makes reusability much smoother if some entities are similar, like

(defn name-with-description [{:keys [name description]}]
  [:span {:title description} name])

> perhaps this is something for ask clojure I'd give that questions as many upvotes as I can.

here ya go https://ask.clojure.org/index.php/10380/when-to-use-simple-qualified-keywords

Unfortunately, I'm unable to provide more than a single upvote!

It’s a question of: 1. scoping 2. use case

if the scope is the argument to a single function, then an unqualified keyword does no harm and is shorter to type

if the use case is, “keys in a hashmap” you always want namespaced keys

if the use case is values in a hashmap, you might want unqualified keywords

e.g. {:http/method :post} is fine

:post in this context is somewhat universal and is never intended as the key in a map, so it cannot clash

On the other hand, if you’re developing a new library with new terms, you might consider a namespace qualifier. {:my/mode :my.mode/fast}

^ does little harm and is slightly easier to use tooling to search for

but the upside is comparatively marginal if :my.mode/fast cannot clash because it’s always a value

Hi there. So I’m playing around with spec and plumatic’s schema at the moment and I’m not sure how to approach this. In Schema, you can have (s/set-fn-validation! true) run and any function schema I define thereafter will be checked automatically. I notice that in spec I can do (stest/instrument) but it only works if I call it after the spec has been defined. Is there a way I can turn instrumentation on first and define specs later? Alternatively, what is the most standard workflow to use spec when deving?

@rextruong one way is to hook this in your (dev) component / integrant-like system, so when you restart it, the specs are instrumented

So every time I define a new function spec I’ll need to restart my dev component you mean?

yeah

similar to routes and a web server I guess

Ah I see. That’s indeed one way to do it.

Actually I may adopt that. Thanks 🙂

Hi there is overloaded java method

serviceConfiguration(Consumer<S3Configuration.Builder> serviceConfiguration) 
serviceConfiguration(S3Configuration serviceConfiguration) 

(.serviceConfiguration ^S3Configuration (-> (S3Configuration/builder)
                                                             (.pathStyleAccessEnabled true)
                                                             (.build)))

Thanks for the input!

A big downside to unqualified is the impact on refactors. We have a large code base. If someone uses an extremely common keyword (e.g., :type), you need to sort through hundreds of uses. It is very likely you'll miss one and potentially break the code in a very nuanced way (yay optional keys).

True, and editors like Cursive and probably other setups too allow refactoring namespaced keywords like vars

The second overload of (.serviceConfiguration ...) that you need receives not one but two aguments - this and serviceConfiguration. You're providing only serviceConfiguration, thus replacing this with it.

my bad it is a bit trickier

(cond-> (S3Client/builder)

             (and access-key secret-key)
             (.credentialsProvider (StaticCredentialsProvider/create
                                    (AwsBasicCredentials/create access-key
                                                                secret-key)))


             endpoint
             (-> (.serviceConfiguration ^S3Configuration (-> (S3Configuration/builder)
                                                             (.pathStyleAccessEnabled true)
                                                             (.build)))
                 (.endpointOverride (URI. endpoint)))

             true
             (.build))

so this seems be provided

and the error i recieve indicates that it expects Consumer

I always wonder why tools.deps does :git/url but then :sha unqualified

The original idea was to have at least one key qualified so we could determine procurer type, but not the others for conciseness

In retrospect, that was dumb

Hmm, right. No idea why, sorry.

thanks

May allow both in the future

Right now I'm designing a task runner "DSL". First I had:

{:task/type :shell (or some other task dispatch key)
 :task/args ...
 ... other task specific opts}

[:shell { optional opts map } ... args ...]

^{:description ...} [:shell { optional opts map } ... args ...]

[:shell {:task/description ...  other opts } ... args ...]

Full example:

{:tasks {:clean [:shell "rm" "-rf" "target"]
         :uberjar [:shell "clojure" "-X:uberjar" ":jar" "foo.jar"]
         :all [:do {:task/description "Execute all steps"}
               [:clean]
               [:uberjar]]}}

It still feels a bit wrong though, to put the :task/description in that spot.

well maybe it's ok, since in HTML you also put "id" etc on random HTML elements of different types

So you'd want to avoid conflicts between :clean, :shell, :uberjar, :do and the like? Some options come predefined (shell, clean, do), others are defined by the user (clean, uberjar)?

Avoid conflicts between options passed to the tasks, e.g.:

[:shell {:task/description ... :shell/opts {...}}]

yes, there is also the issue of user defined clashing with built-ins like :shell, but I don't like [:task/shell ....] [:task/babashka ....] etc, I think

Mhm, it gets too verbose quickly.

instead users can choose namespaced keywords

if there are clashes, or just choose a different name. The user-defined task will always be chosen first, so if they override, they just make something inaccessible for themselves, which is not the end of the world

> instead users can choose namespaced keywords That might make sense, especially if one is referring more to the predefined symbols than ones own additions

it's a similar problem with overriding vars with local symbols in clojure

yeah, I was thinking the same thing.

I really like Clojure's namespacing mechanism.

And as long as you allow the user to override definitions, you won't break users if you add new symbols to the default environment

exactly

maybe I should add a way to always refer to the built-in, e.g. :task/shell will always refer to the built-in, no matter if you overrode (?) it with :shell, like clojure.core/name always refers to the built-in var

(fyi: there's always https://github.com/cognitect-labs/aws-api which I found really nice to use)

I've make a mistake of "namespacing everything with too much cruft" before myself. I had just learned about namespaced keywords. I was designing a data interface with EDN, so I just namespaced everything. How did people like it? It was a hassle. Didn't help that I just used ::key-name in my Clojure file, so there were multiple layers in the namespace as well. I don't want to do that mistake again.

> maybe I should add a way to always refer to the built-in I like that idea.

Could make reusing parts of task runner specifications less problematic.

I think using qualified keywords add a lot of leverage in your codebase, as mentioned before, its great for refactoring, but also for understanding the code base, a find usages in a qualified keyword can give you an accurate view about what that property means across the system (and how its being used). For enumerations is also great, in editors like Cursive, instead of going to look up in a documentation about what are the options, if you have something like :my.task.type/foo and :my.task.type/bar, on typing :my.task.type, you can see the options right there

note that dots in the name part of keywords are not officially supported (if you have :my.task.type as a standalone keyword)

I think he meant typing the namespace part will bring up auto-complete

I mean't more as a prefix for auto-complete, not as an actual keyword (the last one)

right, my bad

@wilkerlucio I'm guessing you're speaking from experience? I'd love to hear examples / instances where qualified keywords have enabled nice workflows.

and also where you'd consider them not necessary.

I do a lot of fully qualified keywords in Pathom for example, and in Pathom I use a more hard-core attribute driven philosophy (and Pathom itself is an expression of this idea), so for example, in the planner (https://github.com/wilkerlucio/pathom3/blob/master/src/main/com/wsscode/pathom3/connect/planner.cljc) or runner (https://github.com/wilkerlucio/pathom3/blob/master/src/main/com/wsscode/pathom3/connect/runner.cljc) you can see a lot of keyword definitions at start. those keywords are mostly used inside the same namespace, but are not limited to it. so when I need get back on feet in some complex part of the code that I haven't touched in a while, I can see which keywords participate in the process, and by following their usages I can quickly remember all the places in which its used. I believe that having consistent property names (close the same way we regard our functions, as an independent being) enables consistent re-usage of these same keywords, and them their semantics can flow over the system

about short keywords, I do use them as well, but I try to avoid most of the time

Thanks for explaining!

hope it makes sense, I'm deep in this rabbit hole :P

haha

(>def ::node-id "docstring" pos-int?)

correct, I'm using Guardrails, which is some syntax on top of spec, this doc is purely for the code reader (you can't access it at runtime)

but you Tony Kay decied to deprecate >def? from https://github.com/fulcrologic/guardrails/blob/develop/src/main/com/fulcrologic/guardrails/core.cljc#L749-L755.

I wasn't aware of that, not sure why its on deprecate list (@tony.kay maintains Guardrails), gotta understand why

For the record, I've spent enough time guessing what "name" can actually be for JSON documents in codebases to be curious about a better way.

@imre sorry for derailing your thread 😅

This is the sort of discussion I was hoping for 😄

I might link this thread into the askclojure once it's available in the log

@teodorlu on your "name", issue, that's a great case to start seeing it, unqualified names always require some context to understand, but a lot of times this context is implicit, and then its up for the reader to interpret it. being fare, its easy in a lot of cases, but the worst is when you are confident, but wrong at the same time. this is the kind of problem qualified keywords can eliminate, if they are big enough (same considerations as for functions), you can always be confident about their meaning, no need to know the context

but its a hard battle, JSON dominates everything, and I find unlikely that the industry is changing in that direction anytime soon, so for those wanting this path, there is a lot of "naming expansion" to be done while interacting with external sources of data, but I believe in Clojure world we are much closer, and we could have a nice ecosystem of qualified names here

FWIW JSON totally accepts "foo/bar" keys

GraphQL however, maybe not, I found their support for these kinds of things lacking in some respects when I checked it out some years ago. A step back from RDF.

The whole "hard-core attribute driven philosophy" makes a ton of sense to me when I hear people talk about it but then I do tend to struggle with how exactly to implement it when I sit down to code something. Thus I can never get enough of these kinds of discussions 🙂

aws-api rather limited in its possibilities anyway, I’d like to understand how to type hint param so clojure can be proper method

maybe I'd remove -> and use simple chains (or let). -> can introduce some uncertainty if you aren't intimately familiar with it as a second trick, you can println the class of the object being built. maybe it's not what you think it is and as a last resource, you could use java's reflection api directly instead of clojure interop syntax

ok, thanks

My general conventions here are informed by a lot of re-frame use and Clojurescript having weaker support for namespace aliasing: 1. Internal to a namespace: unqualified generally 2. If it’s being shared out (eg. a re-frame handler key) then it gets namespaced. 3. Auto-namespacing is only to be used for internal reference to a global thing (eg. the re-frame database … (assoc db ::data-belonging-to-this-ns ,,,) … ugly, but it helps to track down its provenance in tools like re-frame-10x 4. No auto-namespacing ever for anything intended to be shared. It breaks grep and :: looks too much like : when I’m tired. I know things like clojure-lsp and cursive can overcome this but I like to keep lowest-common-denominator outside-the-editor tools like grep working OK.

(I also would put in a big upvote for related guidance on the idea that code namespaces and keyword namespaces don’t necessarily need to be conflated … when should they be kept in sync and when is it wiser to let them drift. IMO the conflation of the two leads to some pretty ugly and un-readable namespaced keywords. Sometimes I find a domain concept namespace hierarchy on keywords helpful and this doesn’t necessarily match up cleanly to the location of code files in a directory tree).

Im really looking forward to https://clojure.atlassian.net/plugins/servlet/mobile?originPath=%2Fbrowse%2FCLJ-2123#prompt?redirectUri=%2Fbrowse%2FCLJ-2123, that will reduce the annoying part of big names, by making it easier to alias, specially for the pure domain cases