Looking at method values changes. I think that's the last chunk of work before next release - if there's something else (tickets) that people want to see included let me know
I wonder about the value of method values for CLJS. Does it really improve UX that much? Stuff like Math/abs already works like a function. Could it be that introducing method values introduces ambiguity in the way people currently already do things? What would be an example where method values really improve the current state of doing things?
Or are you approaching this more from a compatibility standpoint?
E.g.: (String/.length ...)?
combined with :refer-global :only [String]?
The value of method values for CLJS seem a bit questionable to me, to be honest with you. So I'm wondering mostly about good examples where they really make sense.
no ticket, but a closure compiler upgrade would be nice. its broken again due to some DiagnosticGroups being renamend/removed again.
user=> (require 'cljs.closure)
Execution error (NoSuchFieldError) at cljs.closure__init/load (REPL:146).
Class com.google.javascript.jscomp.DiagnosticGroups does not have member field 'com.google.javascript.jscomp.DiagnosticGroup STRICT_REQUIRES'
that is with the v20250820 version. not sure if there is something else broken. I didn't investigate further yet.also still not much of a fan of method values given the dynamic nature of JS and no real classes/interface it all could tie to like on the JVM/Java. I mean most of the time you do not even have access to any information whatsoever about a given "class" when looking at npm stuff, i.e. they give you an instance via exports, but not the type
method values - primarily about compatibility, that's really it - and I don't think that hard to do. It also opens the door for resolving some really annoying stuff that's stuck around.
like PersistentVector/EMPTY not working etc. - it's not directly related but making that work might as well wrap it up.
re: DiagnosticsGroups - gotcha
other annoying cases - GCL enums