<headius>
I updated all checkboxes on 2.7, 3.0, and 3.1... looking pretty good
<headius>
the module stuff is an important item, also expanding the scope of refinements, maybe that module thing (big job, probably miniscule payoff)
<enebo[m]>
yeah the second thing is fine
<enebo[m]>
I did not look at first one
<headius>
it is pretty minor but I wasn't sure the right way to detect that kwargs were passed in
<enebo[m]>
you need to capture TC.callInfo and check the flags for CALLINFO_KEYWORD
<enebo[m]>
I am on a branch so that is from memory
<headius>
aha ok
<headius>
I figured it was in TC somewhere
<enebo[m]>
Actually I switched back and there might be an issue to consider
<headius>
this is very similar to MRI FWIW
<headius>
they have something that goes to the current frame or whatever
<enebo[m]>
populators will wipe that value unless forward = true on the JRubyMethod
<headius>
rb_keyword_given_p I think
<headius>
ok
<enebo[m]>
yeah they have a ci which is its own thing per call
<headius>
so any method that wants to know it got kwargs should have forward=true
<headius>
or in the future an additional argument
<enebo[m]>
we have a single thing which is more complicated because, for example, if you want to propagate those keywiords to an immediate child call you need to leave that value alone
<enebo[m]>
That sounds fine but if you happen to do something like to_s on a parameter it wipes callinfo out
<enebo[m]>
so you have to save it
<enebo[m]>
so it is brittle
<headius>
right so it is similar to backref state
<enebo[m]>
with that said it is literally a single field so it is cheaper than what MRI does
<enebo[m]>
ultimately for native methods we would just want a accepts_keywords = true and then have it as some kind of extra field
<enebo[m]>
Or possibly an index or something
<enebo[m]>
there are multiple ways to skin that cat but that is a bigger project
<enebo[m]>
naming required and optional keywords and whether rest and having all of those just be positional args probably would work well too but scan_args-like behavior is what we really want in the descriptor
<enebo[m]>
headius: yeah examine InvocationMethodFactory and search for "callInfo". I think we call this provisionally something which will change once we do a richer design (e.g. so we shouldn't pick a great name) but "forward" might be weird since any place where we have to ask if we have keywords by examining callInfo needs to set something so we do not reset the field on entry to a native method
<enebo[m]>
it was originally named forward because the only errors I encountered with things like new which need to push the callInfo status to initialize
<headius>
keywords = true would be simple enough until we have a richer way to specify that they should be passed as individual params
<enebo[m]>
well so long as keywords can fit into an unyet made scheme that would be fine to change it to that
<enebo[m]>
I guess ultimately we cannot let this become public for extensions if it changes
<headius>
the eventual design will have to have a descriptor of some sort passed on call stack to ensure the receiver can decode which positional args are what
<enebo[m]>
yeah
<headius>
it's all in my head
<headius>
need to take some smaller steps and simplify the logic for binding native calls
<enebo[m]>
It may even be keywords = true still but then have other fields in the annotation descrbing it better
<headius>
I am sure we can get simple kwarg cases to pass through shortly have 9.4 is out
<headius>
like the dozens of cases that only take one boolean kwarg
<enebo[m]>
yeah there are multiple ways to go
<headius>
exception: true etc
<enebo[m]>
ultimately if should be positional per known kwargs and one for rest
<enebo[m]>
and also ultimate is it also is just a positional param to java method signature
<enebo[m]>
but describing this can be done many ways
<enebo[m]>
can annotations read parameter names themselves?
<enebo[m]>
I suppose we can read the method in processing it
<headius>
Right, once I get a more programmatic way of binding positional arguments in the Java signature to their appropriate positional or keyword arguments We should be able to support a wide range of signatures and avoid boxing for most cases
<headius>
The annotation processor can see that information yes
<headius>
Either offline or at runtime with reflection
<enebo[m]>
yeah ok well forward should become keyword I guess at this point
<enebo[m]>
Thinking about binding foo: to param foo is a neat idea but it needs to mangle for m17n
<headius>
Only for native functions, which are practically all going to be US ASCII
<headius>
Or at worst Unicode
<enebo[m]>
esoteric gem of some kind but that would almost certainly be unicode