tiny-remapper
tiny-remapper copied to clipboard
Add an API for querying inheritance
[2:38 PM] coderbot: patchwork needs inheritance information for figuring out when a class extends a given Minecraft class (I want to have a system for automatically detecting forge features used by a mod), and/or figuring out the list of classes that a giuven class extends (for propagating event bus handlers) [2:39 PM] coderbot: it also needs to know if a mod extends a vanilla class for the purposes for evaluating how a mod uses their ATs for the purposes of remaking them into mixins [2:39 PM] coderbot: if tiny-remapper had a general purpose API for querying inheritance, that would be great
As Player suggested on Discord, it seems like ClassInstance#children fufills this requirement, but there would need to be a public interface for accessing it.
@sfPlayer1 Does this https://github.com/FabricMC/tiny-remapper/blob/4d0c5a803efa90b6a06ecb09b7e8e50384c74384/src/main/java/net/fabricmc/tinyremapper/api/TrClass.java#L19 api fulfill the needs? If yes, we can close this issue.
You can only get parents through the current API, not the childern. But I think it's possible to add an API for this. This will up to @sfPlayer1 .
Querying children is always unreliable, as even the JVM doesn't know the full set of children for any non-final (or non-sealed) class at runtime; new classes can always be loaded to extend an existing class.
Querying children is always unreliable, as even the JVM doesn't know the full set of children for any non-final (or non-sealed) class at runtime; new classes can always be loaded to extend an existing class.
What you said is true in general. However, for tiny-remapper, if you give all class files into tiny-remapper, then it does know all the children (ofc limited in what your input is). And there is a field ClassInstance#children that contains this information after the propagation stage.
Just need to add
Collection<TrClass> getChildren() {
return Collections.unmodifiedList(this.childern);
}
should do the trick. However, some consideration is needed.
- Should we return
TrClassorString? - Should we also have
getParents? - Is this good as an API design?
for the purpose seen in the original issue, I think getting the parent is enough.
In addition, we have https://github.com/FabricMC/tiny-remapper/blob/4d0c5a803efa90b6a06ecb09b7e8e50384c74384/src/main/java/net/fabricmc/tinyremapper/api/TrClass.java#L20 So I argue that our current api suffices for the use cases.