fabric-loader
fabric-loader copied to clipboard
FabricMC
Inverse field and method mapper
Quite a rare usecase, but without this PR it's annoying when you do need it. Because it's so rare, the mappings are lazily computed to save memory.
Whats the usecase?
Would it be easier to read in the mappings from mappings/mappings.tiny ?
Whats the usecase?
I need a field name which is consistent both across Minecraft versions and across mapping environments (both dev and prod), where I am reflectively listing a set of fields. Concretely, I need some form of identifier for the vanilla Materials, and they don't come with one, but their intermediary field names in the Material class would do nicely.
Would it be easier to read in the mappings from
mappings/mappings.tiny?
Not if this gets merged in, it wouldn't :P
Also, we already had unmapClassName, so we may as well have unmapFieldName and unmapMethodName too.
Longer term I was considering to change the API such that the resolver object gets created with a src,dst namespace pair and drops the 1st arg in map*.
