15:55 <kalenp[m]> Good morning, interop question: When calling from java to ruby, I know you can use an interface to bridge that direction, but how do you call a ruby method with kwargs? Does that java interface take a final argument of `Map<String, Object> kwargs`, is there something more idiomatic, or is that just not supported?

16:07 <enebo[m]> kalenp: For 9.3.x and lower if it is a Map and last argument it will work...or should work

16:07 <enebo[m]> For 9.4, you will need to Hash.ruby2keywords(map_thing) and I think or it should end up working

16:09 <enebo[m]> err ruby2_keywords_hash. And also note this will dup the map_thing which makes me wonder if we will need to do something to make this lighter

16:10 <enebo[m]> I am glad you brought this up since it will end up as a problem with keywords being special from 3.0+ Ruby behavior

16:12 <enebo[m]> Until there is something lighter for 9.4 doing something like making a Ruby method which accepts non-kwargs but then **them into the signraute where you really use keywords will be a workaround

16:26 <enebo[m]> https://github.com/jruby/jruby/pull/7431

16:26 <enebo[m]> This should fix the rails issue with zsuper and kwrest

16:55 <kalenp[m]> * a non-kwargs java interface which

16:55 <kalenp[m]> I eventually came up with a solution like your last one which I think I'll use (do it indirectly. a ruby class implementing a non-kwargs interface which calls the kwargs methods), but I was curious enough about how to do it directly that I wanted to hop on and see if I was missing something

16:59 <enebo[m]> kalenp: for 9.3 I believe it should just work as last arg since there is not special kwargs checking happening

16:59 <enebo[m]> 9.4 will be more of an issue and I think we may need to add something since dup'ing a Map means converting everything in it

17:00 <kalenp[m]> what is the type of the kwargs map? Map<String, Object>? Map<Symbol, RubyObject>?

17:00 <enebo[m]> oh

17:00 <enebo[m]> That is a good question. I missed your main question because I have been working on kwargs for 3.0 support :)

17:01 <enebo[m]> I believe second half can be literally anything but first part I don't know. Let me try something. I guess for this to work key must be convertable to RubySymbol

17:09 <enebo[m]> ok I thought maybe we magically did something here with Map but we don't. Then I tried working around it with to_sym in a wrapper and it doesn't. It will work with using RubySymbols as the keys but that is not very broad

17:11 <enebo[m]> kalenp: https://gist.github.com/enebo/9eb97d423710c3e9883f73a04cf90612

17:11 <enebo[m]> I feel like this should work and I am mildly perplexed it gives 0 for 1 here and not something saying no foo: provided

17:12 <enebo[m]> In 9.4 I would expect that error since it is not really a kwarg

17:12 <kalenp[m]> interesting that kwargs are a new distinct type and not just a hash. I guess I haven't been keeping up with ruby3 changes

17:13 <enebo[m]> **h does change the error to String (not Symbol) in 9.3

17:13 <enebo[m]> which technically is what I should have written

17:13 <enebo[m]> Let me retry my hack

17:15 <enebo[m]> So the Map if it is RubySymbol, Anything it will work but as String/RubyString it just does not know it is Java and we just extract based on something being the proper type

17:17 <enebo[m]> I should rescind some statements above...I think using ** will make this work either way in 9.3 and 9.4 since it will be a rest kwarg but the original question of key type is a problem in both

17:18 <enebo[m]> in Ruby 3+ kwargs are first class but ** handles this for 3+

17:19 <enebo[m]> kalenp: to_hash is called when we receive this and you could probably make a wrapper which is a Hash...this is getting a bit weird

17:22 <enebo[m]> I half expected something to happen with this but to_hash is not called in this case: https://gist.github.com/enebo/5d75a524499c24a647c0643a33dbe431

17:23 <kalenp[m]> I think for now I'll go with the 2-step process (interface with flat method calling kwargs method), but we (Looker) would be interested in a more idiomatic method eventually if that was on your radar. We're in the progress of moving more of our code from ruby to kotlin and that means more interop both directions as we call legacy code from new components.

17:29 <enebo[m]> kalenp: feel free to give a use case in an issue and mark as enhancement

17:30 <enebo[m]> It feels like **java_map is a place where we can do something but we cannot do that in a way where all things are impacted

17:33 <kalenp[m]> https://gist.github.com/kalenp/35d68a7de8c6baaeec82dadce0b22900 that's the stripped down version of what we're looking at from our use case

17:37 <enebo[m]> kalenp: conceivably in this example you could make RubySymbol directly as part of mapOf but you don't want all this extra code at all

17:39 <kalenp[m]> it would be nice to not have to pull in jruby as a compilation dependency, but barring that, we could use a RubySymbol there. if we did that, do you expect it would work?

17:40 <enebo[m]> I think so? but Map<RubySymbol in interface and not String

17:40 <enebo[m]> It is not explicitly doing **map so it might still be the 1 for 0 arity error

17:41 <kalenp[m]> from the java/kotlin side, how would you splat the kwargs?

17:41 <enebo[m]> yeah how can we even specify that

17:42 <kalenp[m]> "splat the kwargs", lol

17:42 <enebo[m]> we have no calling convention for it in 9.3 anyways. In 9.4 since it is a tracked special thing Hash.ruby2_keywords_hash might be a possibility

17:42 <enebo[m]> or something similar for java which can do the same thing that is done for Hash

17:43 <enebo[m]> I think the mechanism for this on Java side could be we make an interface you can mark to say you want it to be kwargs hash maybe?

17:44 <enebo[m]> That does mean whatever you pass in must implement it but I am not sure how we kwrest pass a param using Java syntax...marking with a Type seems like one way. Perhaps annotation is another?

17:46 <kalenp[m]> 🤷getting beyond my knowledge of jruby internals here

17:47 <enebo[m]> kalenp: in this case though I think this is mostly just how do you specify something on the Java side

17:48 <enebo[m]> Java specifically is the odd thing out here since it has no kwargs so how do we indicate something in Java (e.g. this param is an X)

17:49 <enebo[m]> internally we would still need to go "oh this thing is X. Now how do we make that kwarg internally"

17:49 <enebo[m]> At this point anything as last param is just an ordinary Map parameter so we treat it as arg n in an argument list

17:54 <kalenp[m]> that makes sense. if I attach that gist to a bug, is that a good motivating example for you guys to track?

17:55 <enebo[m]> kalenp: yeah. It is a good start. A pure-Java example would not be bad either but this shows the basic issue

17:55 <kalenp[m]> looking again, I can streamline it even a bit more, since you don't care why we want to be calling the kwargs method, that's just how I got here

17:55 <kalenp[m]> sure, I can try to translate the kotlin to java

17:57 <enebo[m]> kalenp: cool.

17:57 <enebo[m]> we are pretty heads down trying to get 9.4 out but this appears like it will continue to be a use case we will hit since more and more Ruby is using kwargs

17:58 <enebo[m]> by end of month hopefully we have 9.4.0.0 out and we can look at some stuff like this

18:30 <kalenp[m]> https://github.com/jruby/jruby/issues/7433

18:31 <kalenp[m]> I've got a workaround for now, but thanks for the discussion. Good luck with 9.4! We're working on getting ourselves upgraded to the latest 9.3 right now, too.

18:43 <enebo[m]> kalenp: thanks!