feat: Add CtExecutable.addParameterAt

[algomaster99]

#3884

This PR provides an API to add a parameter in CtExecutables at a specified position. Since there are few classed which inherit from CtExecutableImpl, we should test this API for all those classes.

• CtConstructor
• CtMethod
• CtLambda
  - CtAnonymousExecutable (cannot add parameters to an anonymous class in Java)

[algomaster99]

Passing the argument as is (without type casting) was throwing a compilation error.

incompatible types: spoon.reflect.reference.CtTypeReference<java.lang
.String> cannot be converted to spoon.reflect.reference.CtTypeReference<capture#1 of ?>

I was getting confused with the types as it wasn't even allowing it to type cast to CtTypeReference<String> so I just used a raw type for now. Need help resolving this :)

[slarse]

The type parameters must match between CtParameter and CtTypeReference.

CtParameter<String> first = factory.createParameter();
CtTypeReference<String> firstType = factory.Type().stringType();
first.setSimpleName("y");
first.setType(secondType);

The reason you can't cast to CtTypeReference<String> is that casting is a runtime thing, and the type parameter of a generic type is erased at compile time. That is to say, the JVM does not know the parameterization of a generic type. It's the same reason you can't do stuff like list instanceof List<String>. You can read about type erasure here. It's quite fascinating, and massively annoying.

[algomaster99]

You can read about type erasure here. It's quite fascinating, and massively annoying.

😂. I shall read about it. I remember you mentioned this concept in one of our meetings.

By the way, can you run the workflow for this PR? I will be able to resolve if anything breaks.

[algomaster99]

CtAnonymousExecutable (cannot add parameters to an anonymous class in Java)

Do we need to write a test case for it? We can test if the unit test throws an Exception.

[slarse]

CtAnonymousExecutable (cannot add parameters to an anonymous class in Java)

Do we need to write a test case for it? We can test if the unit test throws an Exception.

That's an @UnsettableProperty, right? Not sure if those are typically tested, @monperrus?

Also, @monperrus approve workflow run please :)

[algomaster99]

That's an @UnsettableProperty, right?

Yes. Let me know if they are still tested. Logically speaking, the test should be written (if it does not exist) for the decorator itself so we don't need to repeat it here.

[slarse]

FYI waiting for workflow run approval from @monperrus before review.

[monperrus]

run approved!

[slarse]

This looks excellent to me.

The overall architecture has the same problem with code duplication as mentioned in #3896, but it's not really the place of either of these PRs to fix that. So I think we should merge this, and deal with the code duplication (which was there to begin with) separately.

@monperrus I vote for merge.

[monperrus]

Thanks @algomaster!

In Spoon, we have one comment line per test that states the test intention, the contract that is being tested. By convention, it starts with // contract: eg

// contract: adding an element to the list increases its size

Could you add this contract line in each new test?

[algomaster99]

@monperrus I added the contract for each test case in this PR.

[monperrus]

Thanks a lot. LGTM, will merge.

[monperrus]

Thanks a lot for your contribution!

[slarse]

@algomaster99 Congrats on your first contribution to Spoon!

[algomaster99]

Thanks a lot! :)

I will move ahead and use this API in diffmin. How can I find the SNAPSHOT version?

[slarse]

@algomaster99 The snapshot version is already used in diffmin. When you specify 9.1.0-SNAPSHOT, Maven will fetch the latest snapshot for 9.1.0. We publish a snapshot on each push to master in Spoon, so it should be up by now.