This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-11
Channels
- # announcements (3)
- # babashka (6)
- # babashka-sci-dev (37)
- # beginners (39)
- # calva (1)
- # clj-kondo (55)
- # clj-on-windows (1)
- # cljdoc (1)
- # clojure (30)
- # clojure-dev (3)
- # clojure-europe (8)
- # clojure-losangeles (1)
- # clojure-morsels (1)
- # clojurescript (26)
- # conjure (8)
- # graalvm (5)
- # helix (6)
- # hyperfiddle (12)
- # meander (6)
- # minecraft (1)
- # pathom (17)
- # polylith (1)
- # releases (2)
- # shadow-cljs (2)
- # sql (1)
- # squint (4)
Would it be possible for Babashka to expose a list of the classes/interfaces it supports somehow? Basically the equivalent of (concat (keys babashka.impl.classes/base-custom-map) babashka.impl.classes/java-net-http-classes (:all babashka.impl.classes/classes))
or something along those lines. Or does it already?
clojure supports (ns-imports *ns*)
which bb does too, but this doesn't give you everything. so I think we'd have to invent something custom for it, right?
I think so, yeah. With Clojure, I use java.lang.module.ModuleFinder
to list all Java base classes/interfaces etc. So I’m looking for something similar here.
we could also expose the reflection config json which is already part of the resources
this is pretty easy to do, just add the resource as a built-in similar to how it's done in clj-kondo
Cool. :thumbsup: This wouldn’t affect binary size, either, since reflection.json
is already baked in, but how about memory use? I’m guessing not?
I guess you’re referring to this: https://github.com/clj-kondo/clj-kondo/blob/cb55e73bb8ce668e437eafb14901bdd8b73a133e/src/clj_kondo/impl/cache.clj#L13-L33
> reflection config json which is already part of the resources So can I already access that JSON file somehow in the current Babashka version?
@flowthing https://github.com/clj-kondo/clj-kondo/blob/ded50286d3e7f192b714ac07980c85bd9a3f19f5/resources/META-INF/native-image/clj-kondo/clj-kondo/native-image.properties#L4
and probably we have to tweak the io/resource
implementation also a bit to fall back on the clojure version of io/resource
Simply exposing babashka.impl.classes/all-methods
would actually give me all I need, I think. Of course, I don’t know whether that makes for a sensible API. Could also add a wrapper that just does (map (fn [{:keys [class name]}] (symbol (.getName class) name)) (babashka.classes/all-methods))
to get a list of fully-qualified symbols.
So it’s all there already, would just need to figure out an API that makes sense and expose it.
No, all-methods
. That way I could offer auto-completion for those (and only those) methods Babashka actually supports.
I’ll take the “fully-qualified symbol” suggestion above back, though — that only makes sense for static methods.
Hmm, except that I would also need a way to distinguish between static and instance methods…
I think for now you could just make a one-one snapsnot of all classes in bb and keep that around in your tool?
> if I give you all classes, you can derive all methods from that Right, that’s true. :thumbsup: