review1: feature: CtTypeParameter#getTypeErasure()

[pvojtechovsky]

Adds new method:

• CtTypeParamer#getTypeErasure() - returns type erasure of generic parameter

This method and #1225 are needed to correctly detect whether method overrides another method following specification

[spoon-bot]

Revapi Analysis results

Old API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-20170311.234506-76

New API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-SNAPSHOT

Detected changes: 2.

Change 1

Name	Element
Old	none
New	method spoon.reflect.reference.CtTypeReference spoon.reflect.declaration.CtTypeParameter::getTypeAdaptedTo(spoon.reflect.declaration.CtType)
Code	java.method.addedToInterface
Description	Method was added to an interface.
Breaking	binary: non_breaking, source: breaking, semantic: potentially_breaking

Change 2

Name	Element
Old	none
New	method spoon.reflect.reference.CtTypeReference<?> spoon.reflect.declaration.CtTypeParameter::getTypeErasure()
Code	java.method.addedToInterface
Description	Method was added to an interface.
Breaking	binary: non_breaking, source: breaking, semantic: potentially_breaking

[monperrus]

getTypeErasure is an excellent idea, thanks.

To me, the type erasure is computed when the type parameter is used not defined. This means that getTypeErasure should rather be in CtTypeParameterReference. What do you think?

(also could we split the discussion of getTypeErasure and of getTypeAdaptedTo in two separate PRs?)

[pvojtechovsky]

Computing whether method A overrides method B uses type erasure. So it is not linked to CtTypeParameterReference. But we can have this method on both CtTypeParameter and CtTypeParameterReference. I personally need it on CtTypeParameter

split the discussion of getTypeErasure and of getTypeAdaptedTo in two separate PRs

I will check if it can be split

[monperrus]

Computing <https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2> whether method A overrides method B uses type erasure. So it is not linked to CtTypeParameterReference.

I'm not sure about this. In a signature `T foo(U x)` both the return type and the parameter types are CtType(Parameter)Reference. The method signatures don't contani CtTypeParameter directly.

[pvojtechovsky]

There are two types of type erasures. Till now I though only about this case:

class<A extends InputStream> {
    A stream;
    <B extends Reader> void setReaderLike(B reader) {}
}

Such typed parameters naturally computes erasure using code on CtTypeParameter (like it was in this PR till now).

Note that

• both CtTypeParameter and CtTypeParameterReference directly contains superClass/superType, which represents their bound.
• only CtTypeParameter has declaringType.

The bound and declaringType are needed to compute type erasure. So from that point of view thos code belongs 1st to CtTypeParameter. And from client's point of view it makes sense life easier if API for CtTypeParameterReference exists too.

But thanks to your note, I see now that there is another place where type erasure makes sense:

class X {
   void processList(List<? extends Reader> list) {};
}

In this case there is no CtTypeParameter or CtTypeParameterReference involved at all. In this case we need new method CtTypeReference#getTypeErasure()

So I suggest these steps:

1. to merge this PR with CtTypeParameter#getTypeErasure() only. (I will remove getTypeAdaptedTo)
2. to create another PR, which handles type erasures on all type references CtTypeReference#getTypeErasure(). This code will sometime call CtTypeParameter#getTypeErasure() and sometime it will use new algorithm, which is not implemented yet.

OK?

[pvojtechovsky]

Now this PR contains only plain CtTypeParameter#getTypeErasure().

Please review. Thank you!

[spoon-bot]

Revapi Analysis results

Old API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-20170315.164827-83

New API: fr.inria.gforge.spoon:spoon-core:jar:5.6.0-SNAPSHOT

Detected changes: 1.

Change 1

Name	Element
Old	none
New	method spoon.reflect.reference.CtTypeReference<?> spoon.reflect.declaration.CtTypeParameter::getTypeErasure()
Code	java.method.addedToInterface
Description	Method was added to an interface.
Breaking	binary: non_breaking, semantic: potentially_breaking, source: breaking

[pvojtechovsky]

I have to think/learn more about generics and parameters. May be you are right that CtTypeReferences has to be involved more in the Type erasure process...

[pvojtechovsky]

I have simplified computing of type erasure and I added CtTypeParameterReference#getTypeErasure too. Is such implementation OK, or did you expected something more for CtTypeParameterReference#getTypeErasure ?

[monperrus]

The signature CtTypeReference<?> getTypeErasure() is clear.

However, I'm not sure about the location.
What about putting this method in CtTypeReference? or even maybe in CtTypeInformation?

[pvojtechovsky]

I like this idea!
I implemented it as CtTypeInformation#getTypeErasure()

[spoon-bot]

Revapi Analysis results

Old API: fr.inria.gforge.spoon:spoon-core:jar:5.7.0-20170403.163958-30

New API: fr.inria.gforge.spoon:spoon-core:jar:5.7.0-SNAPSHOT

Detected changes: 1.

Change 1

Name	Element
Old	none
New	method spoon.reflect.reference.CtTypeReference<?> spoon.reflect.declaration.CtTypeInformation::getTypeErasure()
Code	java.method.addedToInterface
Description	Method was added to an interface.
Breaking	source: breaking, semantic: potentially_breaking, binary: non_breaking

[spoon-bot]

Revapi Analysis results

Old API: fr.inria.gforge.spoon:spoon-core:jar:5.7.0-20170403.191725-31

New API: fr.inria.gforge.spoon:spoon-core:jar:5.7.0-SNAPSHOT

Detected changes: 1.

Change 1

Name	Element
Old	none
New	method spoon.reflect.reference.CtTypeReference<?> spoon.reflect.declaration.CtTypeInformation::getTypeErasure()
Code	java.method.addedToInterface
Description	Method was added to an interface.
Breaking	binary: non_breaking, source: breaking, semantic: potentially_breaking

[monperrus]

Thanks Pavel.

[pvojtechovsky]

Thanks Martin.