papermc / codebook Goto Github PK
View Code? Open in Web Editor NEWLibrary for handling jar remaping logic for PaperMC
License: GNU Lesser General Public License v3.0
Library for handling jar remaping logic for PaperMC
License: GNU Lesser General Public License v3.0
Various collection types have methods that return booleans based on some condition, like if the element was successfully added or removed. The boolean local var names can be added
or removed
or something similar.
For more consistent cross-version comparisons it would be useful for codebook to be able to name parameters similarly to how it names the lvt.
If we don't apply any parameter names, we will get a different mess depending on the version ($$x
or snowman emoji names).
And when using parchment, we don't have mappings for every snapshot, so there is a large amount of redundant diff each version from the mappings getting more or less in sync/complete.
Having codebook generate parameter names in a consistent manner would solve this problem and give us much cleaner diffs.
Various methods on CompoundTag return a type based on a key input which is a string. Very commonly, that string is a constant which is easy to lookup when choosing a name for the local var. The local var should be named based on that string, completely ignoring the expected type.
There are a lot of getAs methods, like on nbt, or gson-related things. These should be filtered out, and the remaining text should be checked against java keywords so we don't end up with _long
and _int2
vars which currently exist.
Currently, if the mappings are completed for an interface and that interface is used to create a lambda, the parameters of that lambda do not inherit the names from the interface.
Some examples in the source, in ExecuteCommand
, the field CALLBACK_CHAINER
's inner lambda does not have the correct parameter mappings which are set for ResultConsumer
. Also in FillBiomeCommand#makeResolver
, the returned lambda for BiomeResolver
does not inherit parameter names from the interface.
The integer returned by Enum#ordinal
should not just use the i#
format, but should be something associated with the type of the enum, like for Direction
, it could be directionOrdinal
.
All in the name of reducing the number of primitive local variables that have numbers after them.
There are several useful reports that could be generated from a run of codebook.
An ItemStack constructor that uses one of the static fields in Items.java
should have its local var name be associated with that item name. So something like
ItemStack itemStack = new ItemStack(Items.ENCHANTED_BOOK);
should be
ItemStack enchantedBookStack = new ItemStack(Items.ENCHANTED_BOOK);
A lot of the methods on Registry, HolderGetter, HolderLookup, RegistryAccess take ResourceKey
as the sole parameter returning something. A lot of the time, those ResourceKey arguments are obtained from static final fields somewhere which makes choosing the name for the local var very easy.
Something like
Holder<Structure> structure1 = registry.getHolder(BuiltinStructures.NETHER_FOSSIL);
can be changed to
Holder<Structure> netherForsilStructure = registry.getHolder(BuiltinStructures.NETHER_FOSSIL);
This is similar to #10 and how the various is
and has
methods are handled, by looking at the field used in the parameter.
A non-exhaustive list of methods that this could apply to are:
TagKey#create(ResourceKey, ResourceLocation)
ResourceKey#create(ResourceKey, ResourceLocation)
Registry#get(ResourceKey)
Registry#getHolder(ResourceKey)
Registry#getOptional(ResourceKey)
Registry#getOrThrow(ResourceKey)
Registry#containsKey(ResourceKey)
Registry#getHolder(ResourceKey)
Registry#getTag(TagKey)
Registry#getTagOrEmpty(TagKey)
Registry#getOrCreateTag(TagKey)
RegistryAccess#lookup(ResourceKey)
RegistryAccess#lookupOrThrow(ResourceKey)
RegistryAccess#registry(ResourceKey)
RegistryAccess#registryOrThrow(ResourceKey)
HolderGetter#get(ResourceKey)
HolderGetter#getOrThrow(ResourceKey)
HolderGetter#get(TagKey)
HolderGetter#getOrThrow(TagKey)
(yes there is a typo in Bootstap in the vanilla source)
Bootstap#register(ResourceKey, Object, Lifecycle)
Bootstap#register(ResourceKey, Object)
Bootstap#lookup(ResourceKey)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.