Clojurians Log v2

That was a helpful video. I also find https://www.youtube.com/watch?v=gIoadGfm5T8 helpful. What I think would be more helpful is an explanation of the differences between switching namespaces or staying in the user namespace.

Is there a way to get cljsjs function resolution to work? For things like (.useState js/React 0) it is saying that .useState cannot be resolved.

minor thing - dotted aliases get a warning when defining a REPL using deps.edn - it works but it's a bit confusing

i.e. foo.bar

aliases are keywords and according to the reader https://clojure.org/reference/reader, "They cannot contain '.' in the name part, or name classes."

so I think that's actually a correct warning

@dnolen some reason you're not using namespaced aliases instead? :my/alias instead of :my.alias ?

hrm ok, I don't think I realized that dot was restricted to the namespace part

not sure that's actually enforced anywhere

What exactly does 'name classes' mean in that sentence?

I'm probably missing something obvious

:java.lang.String

as in they should not match the name of a class?

yeah

reduce and java.lang.String are both symbols but follow different paths in resolution so class names are special cases. I assume keywords disallow class names for some place where this collides, but I don't actually know where. iow, I'm not totally sure why this restriction exists.

I see, TIL 🙂 I still wonder why the doubling down there matters. If a keyword doesn't contain a period, it cannot be a class name either?

I guess you'd be more likely to run into a problem with destructuring keyword to symbol (let [{:keys [java.lang.String]} m] ...)

the period restriction I think is primarily intended to push hierarchical naming to namespaces, not in names

That's a good point re :keys. On that note, which one is more idiomatic, :keys [foo] or :keys [:foo]?

the former

👍:skin-tone-3: thank you Alex

keywords were primarily (only?) allowed in :keys originally to support autoresolved keyword resolution

using ::keys or ::alias/keys etc is now preferred

I also recently learned about that restriction. Honestly I think a lot of people are just using this without knowing this restriction. Tracking an issue about that here: https://github.com/clj-kondo/clj-kondo/issues/1179

but this harder to copy/paste or grep, unfortunately... https://clojurians.slack.com/archives/C0744GXCJ/p1614783163120500?thread_ts=1614780607.115600&cid=C0744GXCJ

Not at the moment sorry, but I’m planning improvements in this area.

I did realize that changing it to (js/React.useState 0) doesn't throw the false positive

But (js/document.getElementById ...) does throw the false positive

Hi @cfleming! What is the status of support for navigating to keywords? Mr. @smith.adriane is using namespaced keywords in #membrane for https://github.com/phronmophobic/membrane/issues/16#issuecomment-790070882 (i.e. an intent is [::some-kwd] and there is (defeffect :the.ns/some-kwd ...) ) is it possible to jump from the former to the latter? is/will there be a general support for that or does Cursive require per-framework extension? Thank you!!!

It looks like https://cursive-ide.com/userguide/macros.html might have an answer. It seems like you can tell cursive how to resolve a symbol for a given macro. There's already built in support for the re-frame macros, I wonder if membrane could piggyback on one of those.

Yes, I think so. I think resolving them as one of the re-frame forms should work. I think I’ll also add a generic keyword def that can be used for this purpose, since the re-frame ones will also affect the icon that’s shown in the structure view etc.

https://github.com/cursive-ide/cursive/issues/2519