Clojurians Log v2

No, you should expect the clojure.string functions to take instances of CharSequence, which I think is doc’ed in the namespace docstring

That it works with chars is an accident of implementation

ok so to clarify, do not count on that internal toString to always be there? Got it, thanks!

If you know the input is a char, you can just use Character/toLowerCase ^char c and skip clojure.string entirely. > can I count on this internal toString to skip doing an str if I am expecting chars as inputs? Would it be possible to validate the input at some boundary? Otherwise, you can have some very odd, but technically working, edge cases:

(clojure.string/lower-case {:NAME "JF"})
=> "{:name \"jf\"}"

the API expectations for clojure.string are documented in the namespace docstring, other inputs are undefined. adding validation checks here would make this slower for all current users of these functions.

Oh sorry, I meant my reply for @jf.slack-clojurians. I didn't imply any code changes for clojure.string are needed.

@evg.tso thank you for the note on Character/toLowerCase! I didnt know that existed! definitely makes my code simpler 🙂 In my case, the input is guaranteed to be a character because of where it's coming from, so I dont have to worry about edge cases. @alexmiller definitely understandable, and glad to have the team take this stand!

I attempted that in the past and mbox had enough edge cases that Javamail didn't work well enough for me.

Javamail has some mbox stuff

thanks! taking a look now, looks like the current iteration is under org.eclipse.angus/angus-mail+`jakarta.mail/jakarta.mail-api` if I'm following these ownership-changes correctly

Looks like someone was recently trying something similar, https://baecher.dev/stdout/incremental-backups-of-gmail-takeouts/

will need to update my priors, been along time since I've actually touched javamail, and the world keeps turning

none that will satisfy your use-case

assuming you want to CAS on a field or use one of the relaxed atomics? do you mind filing an https://ask.clojure.org/?

The only thing that comes to mind is gen-class creates a static public final for its :state

I too wanted to cas a field, and ended up writing this https://git.sr.ht/~hiredman/reagents/tree/master/item/src/com/manigfeald/reagents/struct.clj usage here https://git.sr.ht/~hiredman/reagents/tree/master/item/src/com/manigfeald/reagents/ref.clj?__goaway_challenge=meta-refresh&__goaway_id=1729493c8a460ccb9d28045e6031a678&__goaway_referer=https%3A%2F%2Fgit.sr.ht%2F~hiredman%2Freagents%2Ftree%2Fmaster%2Fitem%2Fsrc%2Fcom%2Fmanigfeald%2Freagents#L13

here is the ask I wrote for it https://ask.clojure.org/index.php/10369/add-atomic-field-updaters-to-deftype

here is some discussion in #clojure-dev https://clojurians.slack.com/archives/C06E3HYPR/p1616525665013300

@alexmiller the doc for gen-class :state mentions final but not static, is there a way to force static ?

another thing you could do with static fields (not final) is using them as inline caches https://clojurians.slack.com/archives/C03S1KBA2/p1761340327219339?thread_ts=1761326860.782729&cid=C03S1KBA2

IMHO your best bet at that stage is to just write the minimal Java shim, unless you want to dive into the bytecode compilation rabbit hole. virgil makes it a very tolerable experience in dev, arguably more so than gen-class

@hiredman thanks, I have the exact same problem indeed

Note that as far as I can see in that case the class is emitted with a static, but non-final field. You'd need to compile a to achieve what you need. E: to that end, I wonder if eval ing a (fn ) and calling it in clinit could work