-
-
Notifications
You must be signed in to change notification settings - Fork 351
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
feature: CtLambda#getMethod() and fix of #1159 #1164
feature: CtLambda#getMethod() and fix of #1159 #1164
Conversation
I'd say there is a solution without introducing a new method. What about setting the type to the correct value when it's available or simply overriding |
CtLambdaImpl#getType is already used for different purpose and makes sense too. It cannot be overriden.
I do not understand. Do you mean to have not derived property CtLambdaImpl#executableType, which is set during compilation of model? |
e62b3a1
to
25e855c
Compare
an idea: to replace I suggest that, because the new method getExecutableType is too special. More generic method which returns CtMethod, which is implemented by result of lambda expression, is better. |
25e855c
to
11ca484
Compare
I replaced If somebody needs the getExecutableType, then s/he can call ctLambda.getMethod().getType(). It is the same. I think this code makes sense. The client needs to know, which method is called by lambda expression. What about the method name Note: the tests fails because fix of #1163 is not part of this PR (to keep PR simple). After #1165 is merged this PR will pass tests too. |
11ca484
to
98df1be
Compare
98df1be
to
2e410bb
Compare
Revapi Analysis resultsOld API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-20170204.234700-25 New API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-SNAPSHOT Detected changes: 2. Change 1
Change 2
|
@@ -60,6 +62,12 @@ | |||
CtExpression<T> getExpression(); | |||
|
|||
/** | |||
* @return a method which is implemented by this lambda expression |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@return the method that this lambda expression implements. Must be defined as a non-default method in an interface, eg Consumer.accept().
One question: Is |
I made a test and I do not know whether it should be equivalent or not. Probably be yes. I just know that the expression |
lambda.getReference().getOverridingExecutable().getDeclaration()
Revapi Analysis resultsOld API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-20170205.234548-26 New API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-SNAPSHOT Detected changes: 1. Change 1
|
OK. This really makes sense, and I'm fine with adding this method to lambda, but with a more specific name. Do you prefer |
I like both getOverridenMethod or getImplementedMethod. |
OK, good. I did a spelling mistake: getOverriddenMethod with double r and double d |
Revapi Analysis resultsOld API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-20170206.234614-27 New API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-SNAPSHOT Detected changes: 1. Change 1
|
This PR fixes issue #1159. The issue #1159 is caused by wrong return type of CtExecutableReference created for lambda. Therefore this code failed too:
Now there is a question whether solution of this PR is correct.
In current spoon model the interface
CtLambda
represents both:CtExpression
, which returns an instance, which implements a type defined by result ofCtLambda.getType()
CtExecutable
, which represents an executable element. It means it has parameters, body, thrownTypes ... and return typeThe problem was that return type of executable element was not accessible. Therefore during creation of CtExecutableReference of lambda expression, there was used wrong return type of that executable (see change in
ExecutableFactory
).Now the issue #1159 is fixed - the parameter references are equal.
... but I have found another issue #1163, which causes that
CtLambdaImpl#getExecutableType
actually does not work correctly.