WiP: feature: CtSuperTypeHierarchy

[pvojtechovsky]

CtSuperTypeHierarchy is a new helper class, which provides access to actual type arguments of any super type of type X adapted to type X

[monperrus]

The core responsibility of this new class is adaptType?

[pvojtechovsky]

yes. The core is "to be able to compute details about super inheritence hierarchy", which is needed to deliver these features:

• isSubtypeOf
• adaptType

[monperrus]

OK. We'll have to discuss on how to integrate this kind of feature in the repo, but first, I want to well understand what you mean by adaptType.

Could you elaborate on the example given in the Javadoc?

[pvojtechovsky]

I want to well understand what you mean by adaptType
Could you elaborate on the example

The target of all these small PRs is to be able to correctly detect whether one method overrides another method. So please have a look at this test. There is a complex class hierarchy of generic classes and generic inner classes. There are 3 implementations of method eatMe, which are using different generic types, but which are - after adapting - same

[pvojtechovsky]

I want to well understand what you mean by adaptType.

here is the big picture: I want to implement a refactoring, which will remove method parameters. That needs an algorithm which founds all declarations and implementations of methods with same signature on the same type hierarchy. Therefore I need to correctly detect whether two methods have same signature (method A overrides B). And following java lang specification, one of the steps in the method signature comparation is adapting of type parameters.
Example:

class Parent<T,K> {
  void someMethod(T p1, K p2);
}
class Child1 extends Parent<Integer,Double> {
  void someMethod(Integer p1, Double p2);
}

Now I want to detect whether Child1#someMethod overrides Parent<T,K>#someMethod(T,K). The idea is like this:

1. to take class Child1 and adapt all type parameters of all it's parents to scope of Child1. After adapting is done we get following VIRTUAL (not real spoon) model, which would be represented by sources like this:

class Parent {
  void someMethod(Integer p1, Double p2);
}
class Child1 extends Parent {
  void someMethod(Integer p1, Double p2);
}

In this model it is easily possible to compare method signatures, because type parameters are adapted to scope of Child1.

The class CtSuperTypeHierarchy holds that VIRTUAL model and is able to adapt parameters to scope of Child1. So now it should be more understandable the purpose of this PR.

Now little bit more complicated example to explain why I started with PR #1238.

class Parent<T,K> {
  void someMethod(T p1, K p2);
}
class Child2<M> extends Parent<Double,M> {
  void someMethod(Double p1, M p2);
}

In this case the super type hierarchy model of Child2, where each parameter is adapted looks like this:

class Parent {
  void someMethod(Double p1, M p2);
}
class Child2<M> extends Parent {
  void someMethod(Double p1, M p2);
}

Note the usage of M in second parameter of Parent#someMehod.
In such model the type of second parameter of Parent#someMehod is CtTypeParameterReference, which refers formal type parameter M of class Child2.
And that's the problem of #1238. That CtTypeParameterReference is actually not able to statically reference it's declarer from different scope.
From java point of view that model is nonsense! And yes, such reference is really a special case. And yes, current implementation of CtSuperTypeHierarchy DOES NOT NEED that. So we can close #1238 unsolved if you think it is on bad way.
But may be if such reference would work then it might be helpful in similar analyzes.

[monperrus]

we're getting closer to merge.

• according to the main responsibility, what about renaming class CtSuperTypeHierarchy to GenericTypeAdapterImpl?
• for discoverability, what about adding a static method adaptType in Query?

[pvojtechovsky]

according to the main responsibility, what about renaming class CtSuperTypeHierarchy to GenericTypeAdapterImpl

yes, I am open to better name. But let's wait some more days with merge and name decision until I finish the "method overrides" detection code - it is the main client of CtSuperTypeHierarchy for now and I would prefer to have free hands with further refactoring of CtSuperTypeHierarchy , when something might be done better.

Note: CtSuperTypeHierarchy is able to adapt generic types declared in scope of CtType. I have nearly finished another similar helper class, which will adapt generic types declared in scope of CtMethod. I call it actually CtMethodSuperTypeHierarchy. These two helper classes has similar API, so we can think of some interface, which will be implemented by both of them. But this generic type adaption algorithms are quite complicated in java, so I need more time to do it well.

for discoverability, what about adding a static method adaptType in Query?

At the beginning I though that CtSuperTypeHierarchy is a mapping function, but now I see it is not. So it should be may be moved to different package and does not belong to Query. I guess some method(s) might be added to CtType(Parameter)(Reference).

Explanation: Mapping function has one responsibility, but CtSuperTypeHierarchy has more. There are:

• CtTypeReference adaptType(type) - adapts type into scope of CtSuperTypeHierarchy or CtMethodSuperTypeHierarchy
• boolean isSubtypeOf(typeRef) - detects if typeRef is super type of scope of CtSuperTypeHierarchy
• boolean isSame(typeParam1, typeParam2) - detect whether 2 type parameters are same - this method is WiP...
• boolean isSameSignature(CtMethod, boolean canTypeErasure) - detects if method has same signature (after adapting parameters, etc.) like scope method of CtMethodSuperTypeHierarchy

[monperrus]

I guess this one can be closed.

[pvojtechovsky]

Yes, it's content was already merged by PR #1218