Fork me on GitHub
#babashka-sci-dev
<
2022-09-11
>
flowthing11:09:16

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?

borkdude11:09:14

you mean programmatically?

borkdude11:09:40

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?

flowthing11:09:24

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.

borkdude11:09:31

babashka.classes/all-classes or so?

flowthing11:09:41

Yes, something like that.

borkdude11:09:34

we could also expose the reflection config json which is already part of the resources

borkdude11:09:52

which would be the most accurate way since it reflects what is available in bb

flowthing11:09:09

Indeed. :thumbsup:

borkdude11:09:41

this is pretty easy to do, just add the resource as a built-in similar to how it's done in clj-kondo

borkdude11:09:56

clj-kondo has several built-in transit files

flowthing11:09:29

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?

borkdude12:09:28

yes, and also the accompanying graal settings

flowthing12:09:59

> reflection config json which is already part of the resources So can I already access that JSON file somehow in the current Babashka version?

borkdude12:09:58

no, you need to expose the json file as part of the binary, like in clj-kondo

borkdude12:09:34

not everything in the classpath is automatically included in the binary

borkdude12:09:58

and probably we have to tweak the io/resource implementation also a bit to fall back on the clojure version of io/resource

flowthing12:09:49

I see. :thumbsup:

flowthing12:09:54

I can give that a shot locally.

flowthing12:09:21

See if that’ll give me everything I need.

flowthing17:09:59

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.

flowthing17:09:22

So it’s all there already, would just need to figure out an API that makes sense and expose it.

borkdude17:09:40

do you mean all-classes?

flowthing17:09:43

No, all-methods. That way I could offer auto-completion for those (and only those) methods Babashka actually supports.

flowthing18:09:25

I’ll take the “fully-qualified symbol” suggestion above back, though — that only makes sense for static methods.

flowthing18:09:13

Hmm, except that I would also need a way to distinguish between static and instance methods…

flowthing18:09:38

Well, that should be doable, too.

flowthing18:09:00

I’ll look into it some more.

borkdude18:09:47

all-methods doesn't make sense to me

borkdude18:09:00

if I give you all classes, you can derive all methods from that

borkdude18:09:31

I think for now you could just make a one-one snapsnot of all classes in bb and keep that around in your tool?

flowthing18:09:32

> if I give you all classes, you can derive all methods from that Right, that’s true. :thumbsup:

flowthing18:09:44

> I think for now you could just make a one-one snapsnot of all classes in bb and keep that around in your tool? Yes, that’s the plan.

flowthing18:09:21

> if I give you all classes, you can derive all methods from that > Except that that will also return methods Babashka doesn’t actually support, right? (Not that this is necessarily a problem — I’m not sure yet which I’d prefer, to be honest.)