Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve dispatch for proc-to-iface based on arg count #3136

Closed
kares opened this issue Jul 15, 2015 · 0 comments
Closed

improve dispatch for proc-to-iface based on arg count #3136

kares opened this issue Jul 15, 2015 · 0 comments

Comments

@kares
Copy link
Member

kares commented Jul 15, 2015

currently in edge cases when there's an ambiguous match e.g.

java.io.File.new('.').listFiles { ... } (2 method exists that accept a single function-interface argument)

no matter the passed Proc's arity the FileFilter#accept(File) seems to be used (with a warning being printed) while with { |arg1, arg2| } we can assume that FilenameFilter#accept(File, String) is more desired than the FileFilter#accept(File)

UPDATE: which method will be used will currently depend on env (returned method order)!

kares added a commit to kares/jruby that referenced this issue Jul 16, 2015
... of the block (see jruby#3136) when there are 2 method with different
interface type signature we can improve current (unpredictable) logic

state prior to this commit is printing a ambiguous warning, the picked
method depends on returned getMethods order
kares added a commit to kares/jruby that referenced this issue Jul 16, 2015
so that we cache correctly cases with proc-to-iface dispatch
(per Proc's arity)

as a side effect redundant null checks were removed
and the calculation should now compute the same when using args[]
or the overloaded version (with args splatted)

(closing jruby#3136)
@kares kares added this to the JRuby 1.7.22 milestone Jul 16, 2015
kares added a commit that referenced this issue Jul 16, 2015
... of the block (see #3136) when there are 2 method with different
interface type signature we can improve current (unpredictable) logic

state prior to this commit is printing a ambiguous warning, the picked
method depends on returned getMethods order
kares added a commit that referenced this issue Jul 16, 2015
so that we cache correctly cases with proc-to-iface dispatch
(per Proc's arity)

as a side effect redundant null checks were removed
and the calculation should now compute the same when using args[]
or the overloaded version (with args splatted)

(closing #3136)
@kares kares closed this as completed Jul 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant