Fork me on GitHub
#clojure-dev
<
2020-11-11
>
pyr15:11:11

@alexmiller on a number of occasion we build qualified keywords from simple ones, so I do not know about useful, I think it would be more of a convenience to avoid having to do the extra conversion back to a string

Alex Miller (Clojure team)15:11:11

can you be concrete with what you have at the point where you're making a kw?

borkdude15:11:29

I also regularly need (symbol (namespace ...)) and (symbol (name ...) when I want to go from a qualified sym to a {namespace {name ...}} structure

Alex Miller (Clojure team)15:11:32

really, the best thing to do is to make this a request on http://ask.clojure.org with more information

Alex Miller (Clojure team)15:11:17

ask is the forum we have to receive requests, and allow people to voice interest via voting

Alex Miller (Clojure team)15:11:42

so as a blanket future piece of advice, that is a better place to ask these kinds of things than here

pyr15:11:51

ok will do

seancorfield17:11:40

I have quite a bit of code that goes back and forth between symbols and keywords, as well as transforming keywords, but I think it's good that Clojure requires us to be explicit about that. And I'll post this as an answer on http://ask.clojure.org if I see this question raised there!

Alex Miller (Clojure team)18:11:37

we have expanded some of these conversion options in recent releases (vars to symbols was the worst one). I don't think we're opposed to adding more, but it's a matter of looking at what's needed/useful/common

Alex Miller (Clojure team)18:11:29

based on the frequency of ask, I think there are definite desires around adding/removing/changing qualifiers (probably mostly in kws) too

โœ”๏ธ 6
vncz22:11:48

Likely a stupid question, but still asking out of curiosity: is there a style guide for the Clojure codebase? I'm looking around some java files and I struggle read it through it

vncz22:11:11

There are some parts that I feel would benefit from some blank lines or a better indentation or something like that.

seancorfield22:11:20

@vincenz.chianese Rich has a somewhat unique style for his Java code but the core team have made it clear that they won't accept patches to change the layout. You get used to reading it, over time.

seancorfield22:11:35

His code is self-consistent, even if the indentation and spacing is unusual ๐Ÿ™‚

vncz23:11:00

@seancorfield Thanks for the prompt reply. I was imagining it, I was just curious about that ๐Ÿ™‚

dpsutton23:11:16

Donโ€™t change formatting of lines otherwise untouched in your patch and Iโ€™m sure someone can help you ensure it matches

vncz23:11:43

I'm not gonna send any patch at all โ€” very far from that

andy.fingerhut23:11:31

Most inconsistencies in the indentation style of the Java code were I believe introduced in patches from others. The original Java code is pretty much all in Whitesmith's style: https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style (which I had strangely never seen in 25 years of curly brace language exposure before seeing Rich's code).

andy.fingerhut23:11:30

If it bugs you when reading the code, you can always run a tool like indent on it to put it into a different indentation style, in your own local copy.

vncz23:11:33

Got it. Again, it was mostly curiosity, I can still read the code.

seancorfield23:11:08

Ah, Whitesmith's... that brings back memories! And, yeah, that might explain why an old hand like Rich uses that style (so... not unique, but just a very old, "traditional" style!).

andy.fingerhut00:11:50

GNU indent is apparently for C, and does mostly useful, but some bad things to Java source code, at least with the few options I tried. I found that Google Java format works pretty reasonably as a command line reformatter for entire files, but by design has no configuration options: https://github.com/google/google-java-format

souenzzo10:11:34

@vincenz.chianese If you ever format your code "after a commit", you will lost many information about your codebase. https://erikbern.com/2016/12/05/the-half-life-of-code.html