-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement the NBT name redesign #44
Draft
BenWoodworth
wants to merge
119
commits into
0.12
Choose a base branch
from
0.12-nbt-name-redesign
base: 0.12
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
4 times, most recently
from
May 23, 2024 20:42
41b70f2
to
ccca50f
Compare
Originally the GPL 3.0 license was decided on so that any improvements or derivative projects that benefit from this project would also have to their source be shared and open. However, GPL imposes itself even if this library is only being used as a dependency. LGPL would've been more in line with the original intent for the license, since it more so applies to modification of the project/binaries, and doesn't impose itself on other projects when used as a dependency. (cherry picked from commit 0d5cf0b)
Both use Node 16, and had warnings about it being deprecated. (cherry picked from commit 17412e3)
(cherry picked from commit 7869eaf)
(cherry picked from commit 6f73e0c)
The new GitHub macOS host uses ARM, and the Adopt/Temurin JDKs no longer work since they aren't built for that architecture until Java 11. See: actions/setup-java#625 (cherry picked from commit 6580e06)
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
2 times, most recently
from
May 29, 2024 01:00
84865c8
to
4d49885
Compare
It has been a frequent cause of issues while rebasing by frequently changed without adding anything of substance, and hasn't been contributing any value to the project.
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
5 times, most recently
from
June 6, 2024 19:11
f2b06bb
to
1119e71
Compare
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
4 times, most recently
from
June 17, 2024 06:04
ac18958
to
7050a30
Compare
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
from
June 30, 2024 22:12
7050a30
to
8024160
Compare
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
from
July 27, 2024 17:53
8024160
to
22370b3
Compare
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
6 times, most recently
from
August 10, 2024 17:08
a066834
to
9caf9f7
Compare
Makes it possible to simplify `VerifyingNbtReader` and, then also the implementation of `parameterOfVerifyingNbt` since the verifying readers/writers can all be constructed the same from the `capabilities` that are already provided. In the future, this can also be used when implementing `decodeSequentially`.
Will also be used for the root tag, since its internal representation is going to be a named tag instead of a nested compound.
These were originally added for symmetry with JSON's API. However, the JSON convenience properties are on `JsonPrimitive` instead of `JsonElement`, and are there out of necessity because the underlying type is unspecific and obscured by `JsonPrimitive`. That's not the case for NBT, so these don't provide much value.
Equivalent to the ones that exist for `NbtTag`, making it more seamless to work with named tags when the name is unimportant.
All serializable types now have an `NbtName`, defaulting to an empty name. Simplify naming code by switching away from single-entry-compound code with verification.
All serializable types now have an `NbtName`, defaulting to an empty name. Simplify naming code by switching away from single-entry-compound code with verification.
All serializable types now have an `NbtName`, defaulting to an empty name. Simplify naming code by switching away from single-entry-compound code with verification.
All serializable types now have an `NbtName`, defaulting to an empty name. Simplify naming code by switching away from single-entry-compound code with verification. SNBT now doesn't print root name since it's an unnamed variant, which matches the behavior of Minecraft Java's net.minecraft.data.Main NBT -> SNBT data generator tool with the --dev flag.
All serializable types now have an `NbtName`, defaulting to an empty name. Simplify naming code by switching away from single-entry-compound code with verification. SNBT now doesn't print root name since it's an unnamed variant, which matches the behavior of Minecraft Java's net.minecraft.data.Main NBT -> SNBT data generator tool with the --dev flag.
Simplify naming code by switching away from single-entry-compound code with verification. SNBT now doesn't print root name since it's an unnamed variant, which matches the behavior of Minecraft Java's net.minecraft.data.Main NBT -> SNBT data generator tool with the --dev flag.
TODO: Document in @NbtName. Types that don't have an explicit `@NbtName` will default to having an empty name. The root name is largely redundant, since Minecraft's implementation entirely discards it and just uses an empty string when writing NBT. Giving all types a default name matches Minecraft's behavior, makes serializing with named NBT formats more straightforward for those who don't care about the NBT name, and makes any (3rd-party) serializable type compatible with named NBT out of the box. Tests can now all be run against named-root `VerifyingNbt`, since tests values can now work in named NBT without needing an `NbtName` to be provided.
Element was accurate when copying from `JsonTransformingSerializer`, since it worked with `JsonElement`s, but should've been changed when adapting the serializer to NBT.
There were design issues around providing an `NbtFormat` instance as the default since not all the formats *can* have a default instance. Previously this was worked around by having an illegal instance with values that would be explicitly ignored by the builder using a reference check. The previous approach feels like a code smell, treating an incompletely configured instance as if it were complete when passing it as a default, while requiring special treatment for the "default" instance since it isn't a behavioral subtype semantically. With more specific `NbtFormat` subtypes coming later on, this new approach with objects that provide the defaults should be more wieldy to implement and maintain. The `Default` implementations that required special handling have been removed, and there is now a single source of truth for each option's default value.
Will be split into different implementations for each NBT variant, since each will have slightly different APIs e.g. with Java requiring a named NbtCompound at the root, JavaNetwork supporting unnamed nullable tags at the root, etc.
TODO: Nbt docs
Nbt from any NbtFormat
Does not have any affect currently, but safeguards against format changes being introduced in the future.
BenWoodworth
force-pushed
the
0.12-nbt-name-redesign
branch
from
September 17, 2024 22:20
8ff08cb
to
d1cf19b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #29
Tasks:
NbtFormatBuilder
interfaceparameterizedNbtFormat()
testing functionlistOf(NbtList, NbtByteArray)
is inferred asList<Any>
instead ofList<NbtTag>
Nbt*Array
s withList
s, and encode arrays asNbtList
by default, and require@NbtArray
#34, fixing the problem with elements whose serializers delegate toByte
/Int
/LongArray
s (see here)serializer
is an instance of*ArraySerializer
@NbtNamed
to@NbtName
, retaining the existing NBT names on test classes that have themNbtNamed<T>
class next, that way the later changes have something to migrate to when moving away from the single-entry-root-compound name representationNbtNamed<NbtTag>
to match those onNbtTag
, so that dealing with named tags is more seamless when the name is unimportant. E.g.namedTag.nbtInt
encodeTo
/decodeFromNamedNbtTag()
functions, so tests have a way to check against the serialized representationNbtName.Dynamic
that disables root name validation for a type (and later allows name to be serialized dynamically with encoder/decoder functions)@NbtName.Dynamic
when delegating to another dynamic serializerDynamic
will be considered to have anNbtName
(""
by default). As opposed to requiring@NbtName
or not being named until the name is dynamically encoded, since all types will eventually be implicitly NbtNamed anyway)@NbtName
work on any serializable typeNbtNamed
class serializable. Done after implementing it as an encode/decode representation because those will be necessary for testing its serializationbuildNbtCompound(name)
andbuildNbtList(name)
functions to returnNbtNamed
@NbtName
to only nest under the name for the root value@NbtName
docs, which says it instructs the serialization to nest within an NBT compound so it's namedJavaNetwork
docs: "Serializes unnamed NbtTags for use in network packets"@NbtName
lenientNbtName
configuration option, and name validationJavaNbt
,JavaNetworkNbt(val protocolVersion)
, etc.)Nbt
class. Requiring that they all have the sameencodeToNbtTag()
is forcing an abstraction. In reality, they are all (slightly) different formats, so should each be its ownNbtFormat
implementation (with all the same binary serialization methods, but different in-memoryNbtTag
serialization methods)NbtFormat
providingencodeTo
/decodeFromNbtTag
with all NBT capabilities (named root, nullable root, special floating point values, etc) that fully captures how a class would serialize to NBT, not just how a specific limited variant would be serialized. This is useful for testing/experimenting by library users, but also necessary forNbtTransformingSerializer
so serializer's using it aren't unnecessarily limited by a specific NBT format.