`equals()` semantics on `CtType`?
- Dominant language
- Java
- Stars
- 2k
- Forks
- 392
- Avg merge
- 11h 24m
- Merged PRs (30d)
- 36
Description
I'm trying to understand the semantics of `equals()` on Spoon's `CtType`s.
---
Consider two packages, `a` and `b`, which both contain an _empty_ class `C`:
```
package a
class C
package b
class C
```
In this case, the `equals()` method on `a.C` and `b.C` returns `true`, even though their qualified names differ and they are arguably two different types.
---
In the following case, the `equals()` method on `a.C` and `b.D` unsurprisingly returns `false`:
```
package a
class C
package b
class D
```
---
Now, if we insert two identical methods in `a.C` and `b.C`, `equals()` returns `true` again:
```
package a
class C
void m()
package b
class C
void m()
```
---
But if their names differ, `equals()` returns `false` again:
```
package a
class C
void m1()
package b
class C
void m2()
```
---
It seems that `equals()` is checking for structural equivalence rather than nominal equivalence (but not strictly because in the second case `C` and `D` are not considered equal). Is this the intended semantics? The main issue is that it makes some analyses awkward to write. If I analyze a project with Spoon and insert all its types in a `Set`, many of them disappear, though they are indeed distinct types according to Java's semantics. Generally, manipulating Spoon types in collections is often awkward. It seems that the valid way to check for equality according to Java's semantics is to compare qualified names, or to always use `CtTypeReference` instead which does not suffer from this problem.
---
For reference, the minimal test. This is with Spoon 10.4.2.
```java
@Test
void equals_semantics() {
Launcher launcher = new Launcher();
launcher.addInputResource("spoon-equals");
CtModel model = launcher.buildModel();
CtType ac = model.getRootPackage().getPackage("a").getType("C");
CtType bc = model.getRootPackage().getPackage("b").getType("C");
assertEquals(ac, bc);
}
```
Contributor guide
Assessment
This issue has not been assessed yet.