[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201268#comment-15201268
]
Jochen Theodorou commented on GROOVY-7772:
------------------------------------------
let's concentrate on one point first, overloads...{code:Java}
for(MetaMethod m : methods) {
if (m.getParameterTypes().length > maximumNumberOfParameters) {
Class[] pt = m.getNativeParameterTypes();
maximumNumberOfParameters = pt.length;
parameterTypes = pt;
isStaticMethod = m.isStatic();
}
}
{code}
What happens if there are two methods of the same length?
maximumNumberOfParameters will have the right information still, but
parameterTypes might be one or the other, same for isStaticMethod. You can't be
sure which one is taken, since
InvokerHelper.getMetaClass(clazz).respondsTo(owner, method); does not guarantee
any order. This means that information is unstable. So if you have two methods
with the same number of parameters and the same name, You, as user, cannot be
sure which of those two will be taken into consideration for your
isStaticMethod based logic. You can see that already a bit when you look at
line 63 in MethodClosure in your PR. There you adjust the parameter types,
basically making it more for instance methods. But just before you had a loop
selecting on the length of these parameter types, and there static and
non-static was equal. Why is the non-static version not automatically longer in
the first loop already?
This then leads to line 77. If we cannot be sure that the partial method
selection through the logic before was right, then it is most probably wrong to
build on top of that information and do as if it was right. You see that
parameterTypes plays absolutely no role in doCall. But isStaticMethod is
equally bad. So instead of initializing the MethodClosure with this information.
I think we have to get the information new... That means get the metaclass, ask
it for a instance MetaMethod that fits the given arguments, change the
signature to the static version and ask for a fitting static method. If only
one of them exists, we have a candidate for our call. If both exist, then we
can call either the first or the second... or we produce a
MethodSelectionException. Of course there might be more than one method that
could respond in both cases... those are probably error cases as well
> Class.&instanceMethod had better to have same meaning of
> Class::instanceMethod of Java8
> ---------------------------------------------------------------------------------------
>
> Key: GROOVY-7772
> URL: https://issues.apache.org/jira/browse/GROOVY-7772
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
> Affects Versions: 2.4.6
> Reporter: UEHARA Junji
> Assignee: Jochen Theodorou
> Priority: Minor
>
> Groovy's operator .& for method is similar functionality to Java8's method
> reference operator ::.
> ||No.||lhs||rhs||meaing of Groovy's .& (Closure) ||meaning of java8's ::
> (FunctionalInterface)||
> |1|instance|instanceMethod| { ..args -> instance.instanceMethod(args) | same
> as groovy |
> |2|Class|staticMethod| { ..args -> Class.staticMethod(args) | same as groovy |
> |3|instance|staticMethod| ERROR groovy.lang.MissingMethodException: | Error
> same as groovy (compile error) |
> |4|Class|instanceMethod|error| Function<RetType,Class,Args..>, where method
> instance method of Class which is declared as ```RetType
> instanceMethod(Args..) {...}```. In other words it is interpreted as a
> function which takes LHS Class as the first parameter which additionally
> inserted to the method.)|
> IMHO, i'd like to propose to change the No 4 pattern semantics of groovy
> same as Java 8 's. Because:
> * You can write:
> {code}
> ["a,b,c"].collect ( String.&toUpperCase )
> {code}
> instaed of
> {code}
> ["a,b,c"].collect { it.toUpperCase() }
> {code}
> * Can have correspond operator to java8's ::. which is understandablea and
> needed for Java programmers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
