Something like a follow-up to #489:
Consider this Java class:
package test22;
public class MyBean {
private String foo;
public void setFoo(String foo) {
this.foo = foo;
}
public String getFoo() {
return foo;
}
}
And this Groovy class:
package test22
import groovy.transform.CompileStatic
@CompileStatic
class Test22 {
public Test22() {
def b = new MyBean(foo: 'c')
def m = b.&setFoo
}
}
Invoke Call Hierarchy on MyBean.setFoo(String): I think the reference to this method in def m = b.&setFoo should not be lost and shown in the Call Hierarchy in some way.
Creating an equivalent Java Class and using a method reference (which is much like a Groovy method pointer), I see it shown in Call Hierarchy just like a regular call. We could argue that is not really a "call" (at least where it's just assigned), but at least it is not lost. So perhaps Greclipse should at least mimic what JDT does.
Here's an "equivalent" Java class to test the behaviour:
package test22;
import java.util.function.Consumer;
class Test22Java {
public Test22Java() {
MyBean b = new MyBean();
Consumer<String> m = b::setFoo;
}
}
Something like a follow-up to #489:
Consider this Java class:
And this Groovy class:
Invoke Call Hierarchy on
MyBean.setFoo(String): I think the reference to this method indef m = b.&setFooshould not be lost and shown in the Call Hierarchy in some way.Creating an equivalent Java Class and using a method reference (which is much like a Groovy method pointer), I see it shown in Call Hierarchy just like a regular call. We could argue that is not really a "call" (at least where it's just assigned), but at least it is not lost. So perhaps Greclipse should at least mimic what JDT does.
Here's an "equivalent" Java class to test the behaviour: