Add # to names.

Just like (doc gensym) describes it - it works within macros' bodies.

And you can always see something like (source when-some) and notice how it uses temp#.

thanks, I'm not sure what you mean by "just like (doc gensym) describes it. here is what i see from (doc gensym)

clojure-rte.rte-core> (doc gensym)
-------------------------
clojure.core/gensym
([] [prefix-string])
  Returns a new symbol with a unique name. If a prefix string is
  supplied, the name is prefix# where # is some unique number. If
  prefix is not supplied, the prefix is 'G__'.
nil
clojure-rte.rte-core> 

It doesn't describe how to use #, but it mentions prefix# - can be used as a shortcut to remember it.

so what is happening? is the reader manipulating foo# into a unique symbol, or is this something defmacro does?

for example, sometimes for complicated macros, I write helper function to generate parts of the expansion. can I use foo# in those non-macro helper functions?

outside syntax quote foo# is just normal symbol

https://clojure.org/reference/reader#syntax-quote

tldr; syntax quote is just a template for the code with few rules like ~, ~@ and symbol#

And every new syntax quoted form introduces a new context for #:

user=> (macroexpand `(a# a#))
(a__170__auto__ a__170__auto__)
user=> (macroexpand '(`a# `a#))
((quote a__175__auto__) (quote a__176__auto__))

ahhh it's the syntax quote which does it. I wouldn't have guessed that

so in the rare case that my macro does not use syntax-quote, I have to use gensym

more like “syntax-quote rules are meaningless outside of syntax-quote” so you have to use gensym. But at the end syntax-quote is just some sugar to make macro code looks readable )

for nested syntax quote gensyms there's potemkin's unify-gensyms too

Or you can just (let [s (gensym)] ...) outside of the quoted forms.

yes you can do that but that can get really confusing really quick ("what does a symbol pointing to a symbol mean")

You can use the symbol pointing to a symbol as part of the expression that the macro returns when called. The symbol's value (which is the (gensym) ) is returned as part of the returned expression. Here is a silly example:

user> (defmacro test
        [value]
        (let [x (gensym)]
          (list 'def x value)))
#'user/test
user> (test 10)
#'user/G__31039
user> G__31039
10
user> 

You can use hiccup.util/raw-string for that. But, of course, there would be no nesting. For proper nesting, you'd have to extend the HtmlRenderer protocol with some type that would represent such a comment.

That worked perfectly, thanks

not directly your issue, but I think it would be more idiomatic in clojure code generally to check via satisfies? for the protocol you care about, rather than conditionally checking for some required class (since we so rarely use concrete inheritance, checking for instantiation is usually not helpful)

Thank you @U051SS2EU! I'll check that out! 🙂

My opinion is most succinctly summarized as, :face_vomiting:

Doesn't seem that crazy. I would probably just opt to accept keywords (eg. :http.status-code/ok or something better) if you want to name the status codes in code rather than using my.http/ok. I might additionally create a var in namespace that lists all the known status codes and potentially provides a doc string.

But I have a decades'-long belief that reflection should be reserved for frameworks and low-level libraries and used sparingly there.

It is more useful if you're forced to write interop code with some java library that requires some special enums

it is great

@U01GXCWSRMW I have the same reaction! Our code base only uses like, 15 of these HTTP status vars so it literally would be less code to make this hard coded. I’m not willing to throw static analysis in the trash can so fast.

Also this increases startup time! This seems like code you should use in the REPL to create a bunch of def expressions. Which is exactly what I’m doing 🤓

> Also this increases startup time Every single def increases startup time, the Clojure compiler is quite slow. Here it won't make a difference that a human could possibly notice. Also, reflection is slow if you're going to do it repeatedly, at runtime in a production app but that's not what's happening there. The work is performed once, at compile-time. The impact is a one-off cost of maybe 1ms which is negligible if your app startup time is say 30s or 60s

The code in question seems fine if it has the explicit purpose of easing interacting with HttpURLConnection. If you're creating a generic http lib instead, what seems off is using a random class' implementation details as the basis for that. It's not like HTTP codes will change over time.

@U0NCTKEV8 IIRC usually you're a proponent of interop and you speak against thin wrappers. What's different about this case?

Not a clojure developer, just keen reader, but in typescript world this would be considered an anti-pattern, mainly cause it's overly complex. Maintaining this code seems more expensive than simple hardcoded version, because: 1. Imagine you have bug involving status codes, it seems the debugging would be much harder than for a hardcoded version - this function introduces one more point of failure 2. Imagine a new developer comes - this is a piece of code that you need to share knowledge about with him/her. I can also easily imagine a new developer on the project banging the head against the wall trying to fix bug with status codes and not understanding where they come from, cause you can't find them in the codebase anymore 3. What if someone wants to refactor it? That's additional costs + you need to somehow make sure that refactored version works correctly, it means that ideally you need to write tests

@U019RSW97UZ Another way to go about this would be to not write this as dynamic code but as code that generates code in a file on disk, so it would literally spit out "(def foo ...)" . That avoids doing the dynamic analysis at startup each time and also has the benefit that static analysis tools like clj-kondo would just understand them.

@p-himik the thin wrapper thing is about dependencies mostly. A dependency needs to add substantial value to justify itself(managing dependencies in long running projects is a lot of work)

I might prefer to generate predicates for the different status codes, but that is usage dependent. At work I have some code that reflectively generates predicates for all the different Braintree transaction statuses

I've also statically generated a ton of wrapper interop stuff around http://authorize.net's java sdk

Generating the stuff on disk was to some degree a crutch while figuring out our code to talk to http://authorize.net, it was nicer to look the generated code to figure out what was available and what args different calls needed then digging through their library

I see. In similar cases, when I know the set of the functions I will be working with, I tend to avoid generating any names and instead provide them explicitly, so that there's better tooling support and it's easy to reason about the code by just reading the source. Something like

(defmodel DatetimeAxis datetime-axis datetime-axis? datetime-axis-spec)

You could wrap the reflection up in a macro and generate defs

Indeed, but that's exactly my point - the tooling support suffers, the ability to just read the code suffers (you gotta remember that defmodel also generates a bunch of symbols that you don't see explicitly, and that incurs tiny but unnecessary cognitive load).

I think clojurists, for some reason are much accepting of macros that expand to defs, then code like the above that just calls intern

With the model above, I can easily navigate to where it's defined by any of the symbols in there.

That point you are letting the automation your tools support dictate the kind of code you write instead of writing code and making tools to support it

But there is nothing stopping you from, for example, attaching file and line metadata to intern'ed vars

If that stuff is in it's own namespace, and you only ever :require :as it, do you really need to jump to definition?

> That point you are letting the automation your tools support dictate the kind of code you write Absolutely, everything is a trade-off. I'm also letting English dictate the way I name things, even though there are many places where I could use my native Russian. :) > attaching file and line metadata to intern'ed vars Which still requires tooling support and run time. Also doubt it would work in CLJS since there are no true vars there. > do you really need to jump to definition? I do but of course YMMV. Note that that defmodel example above is an abridged version. It might include many more things that don't have anything to do with words "datetime axis".

I've even got some test code that doseqs over a sequence of values and interns a function marked as a test for each item (I forget exactly why I did it that way, maybe to take advantage of existing fixtures?), effectively generating deftests

Tests are different though, they aren't some API that you use on a daily basis. I wouldn't mind test code generation at all - as long as a test failure makes it crystal clear what's wrong, where, and why.

Also, reflection is great

> But I have a decades'-long belief that reflection should be reserved for frameworks and low-level libraries and used sparingly there. > Reflection is just another source of data for data driven code

Reflection will also save your bacon over and over again, avoiding rewriting dependencies or maintaining forks, and getting access to key functionality

How does that work?

You mean accessing internals?

For some reason people who write java reflexively mark the best code as private

Yeah

We use http://netty-socket.io at work, and it didn't (and I think still doesn't) count characters outside of the bmp correctly, which it needs to do for the http://socket.io protocol

So at work we reach through layers and layers of private and package private stuff to use our own counter

Alternatively I could spend the time and energy of maintaining our own fork, of a project I couldn't even get a clean test run of when I tried to run the tests prior to trying to submit a patch

That's a nice example. Although a nightmare situation to be in.

Software development for business is a series of nightmare situations

:D Depends on the business, but yeah.

I mean, I've been doing a lot of Google play billing work recently, and their java library is a joke for androidpublisher clearly just minimally generated code from their data model

And that is a a serious line of business for a huge company that employs a ton of developers, and a ton of outside businesses depend on it

Just a nightmare

I guess maybe I'm the only one who's had to rewrite a bunch of code the day software was deployed to an environment with the Java SecurityManager turned on preventing reflection?

reflection can break use of a library in a native-image context. You wouldn't be able to run the above code via babashka, for example.