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

Comments

Projects
None yet
1 participant
@kares
Copy link
Member

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

support for matching proc-to-iface methods by arity
... 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

method cache hash calc needs to acount for Proc
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

support for matching proc-to-iface methods by arity
... 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

method cache hash calc needs to acount for Proc
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 Jul 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.