first class support for keyword arguments in ScriptingContainer.callMethod #9402
Replies: 2 comments 1 reply
-
|
Bravo, I never considered this particular situation and you are correct to say that there's no blessed API for embedding users to make keyword argument calls. The situation is aggravated further by using the formal embedding APIs Scripting container and the javax.script package since they don't even allow access to an internal apis without jumping through some hoops. Clearly something needs to be added. Your suggestions seem along the right lines and track with options I have considered for passing keyword arguments more directly to target methods. It might be cleaner for us to add additional method names rather than overloads, like This is actually a problem that has affected JRuby internals as well. The call info dance is too manual and error-prone, as is the receiver-side handling of that metadata. @kares recently audited all uses of call info and found several cases where we did not clear it correctly once inside the call. I'm currently out of the office, but I will continue working on kwargs-on-stack when I return on Monday. It will make sense to also start adding Java APIs for explicitly passing kwargs in that work. Until then we can continue discussing and on your PR. |
Beta Was this translation helpful? Give feedback.
-
|
Closing as we've moved discussions to the PR |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been using JRuby to wrap some pre-existing Gems to be called by Java using the ScriptingContainer interface provided by JRuby 10.x, however, whenever a Gem uses keyword arguments there doesn't seem to be a clean way to force a Map to be treated as the keyword arguments for that Ruby API. I see theres a ThreadContext.CALL_KEYWORD flag I can use, but it seems more an internal implementation detail than something that should be exposed to scripting users. Afaict this works:
What I'm proposing is adding further callMethod method overloads to include a last argument of Map<String, Object> or similar that will become those keyword arguments (convert strings to symbols automatically, call convertJavaToUsableRubyObject() on values, etc. My guess on why this hasn't come up before is that any scripting use cases predated Ruby's 3.2 order argument changes around auto-conversion of the last hash into keyword args. Since 3.2+ that behavior is disallowed so some other mechanism needs to exist going forward. I think what I propose makes sense here, but i could be missing something important.
I'm also assuming that java is able to differentiate between, which I need to experiment with (to verify):
Pre-existing:
and
Proposed:
Beta Was this translation helpful? Give feedback.
All reactions