[
https://issues.apache.org/jira/browse/GROOVY-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185972#comment-15185972
]
Jochen Theodorou commented on GROOVY-7772:
------------------------------------------
I think there is one more point to clear:
{code:Java}
class X {
def m() {1}
def m(int i) {i+1}
}
def ref = new X().&m
assert ref() == 1
assert ref(1) == 2
assert ref.parameterTypes == [int]{code}
As you can imagine code like this would not be possible in Java. It also means.
The implementation guarantees, that the prameterTypes will be corresponding to
the longest signature. If multiple signatures of the same length exists, then a
random one might be taken. In similar fashion this imposes a problem for
determining if we do dispatch on a static method or not in your code. Imagine
for example m() being static and m(int) not, and the reference X.&m. The code
will make a setup for isStaticMethod=false and owner being a Class,
prameterTypes will become [X,int], a call X.&m(1) will incorrectly not work
according to the logic in doCall.
Actually the class has another big problem not caused by this change. If we do
a call to the MethodClosure from Groovy, the meta class logic will be used. But
if we do the call from Java, the logic in doCall will be used. They have to
stay in sync, to show the same effect, which is bad. Good would be one version
using the other. Now for efficiency reasons we have sometimes direct calls from
call to doCall. So at this point I would normally suggest making the class
final and remove the doCall method. call, goes to doCall dynamically, so the
logic in the meta class would still work out... but this would be a breaking
change.. So instead I would let doCall throw an Exception.
Then of course call should not be specified by MethodClosure at all. And of
course the decision if we do a dispatch based on the static method or not, with
an instance or a Class, must be completely in the MetaClassImpl part, you
already touched. But instead of blindly invoking, you will need to get the
MetaMethod and check. for the special case, to blindly invoke otherwise. This
of course also means MethodClosure would not have a isStaticMethod property 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)
