You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
abstractclassBase<TextendsFoo> {
abstractvoidaccept(Tinput);
}
classImplextendsBase<FooImpl> {
voidaccept(FooImplinput); // becomes bridge to method with signature from parent xlass// void accept(Foo input); // Method implementation goes here in actuality
}
Currently the mapping generator will see the two methods in Impl as having different signatures and will thus allow the passed NameGenerator to create unique names for each. For keeping things pretty in the decompiler output, it would be nice if we could have these bridge methods share the same name as the real method taking on the parent method's signature.
I think having a generic system to track "this method is a bridge to this method" would be nice, which once completed could be plugged into the MappingGenerator code with ease.
The text was updated successfully, but these errors were encountered:
Rough idea given the following model:
Currently the mapping generator will see the two methods in
Impl
as having different signatures and will thus allow the passedNameGenerator
to create unique names for each. For keeping things pretty in the decompiler output, it would be nice if we could have these bridge methods share the same name as the real method taking on the parent method's signature.I think having a generic system to track "this method is a bridge to this method" would be nice, which once completed could be plugged into the
MappingGenerator
code with ease.The text was updated successfully, but these errors were encountered: