[x] Replace Kotest's property testing with Parameterize
[x] Tidy up test suite / test data
[ ] Port over recent changes from v0.11
[x] LGPL
[x] "master" branch renamed to "main"
[x] Shared NbtFormatBuilder interface
[x] parameterizedNbtFormat() testing function
[ ] Builtin polymorphic serializer support
[ ] ...
[ ] General
[ ] Split up list-like deprecation interfaces
The NbtList/Arrays all sharing another interface causes issues with type inference. e.g. listOf(NbtList, NbtByteArray) is inferred as List<Any> instead of List<NbtTag>
[ ] Implement #34, fixing the problem with elements whose serializers delegate to Byte/Int/LongArrays (see here)
[x] Remove fast-path optimization with array types for now, as it's making it more difficult to iterate on the implementation. (See b8d52f459ffe7b8b00fbbf3e95c450682e9fb751 which implemented checks against descriptors instead of checking that the serializer is an instance of *ArraySerializer
[ ] Gradually implement new design, ideally keeping all tests valid between each change
[x] Rename @NbtNamed to @NbtName, retaining the existing NBT names on test classes that have them
[x] Refactor encoder/decoder-verifying testing so it will better cover named/unnamed and nullabe/non-nullable NBT formats
[x] Add the NbtNamed<T> class next, that way the later changes have something to migrate to when moving away from the single-entry-root-compound name representation
[x] Add convenience properties for NbtNamed<NbtTag> to match those on NbtTag, so that dealing with named tags is more seamless when the name is unimportant. E.g. namedTag.nbtInt
[x] Add encodeTo/decodeFromNamedNbtTag() functions, so tests have a way to check against the serialized representation
[x] Refactor general NBT serialization checks so they can be shared between the encoder and decoder
[x] Add NbtName.Dynamic that disables root name validation for a type (and later allows name to be serialized dynamically with encoder/decoder functions)
[x] Add checks that require @NbtName.Dynamic when delegating to another dynamic serializer
[x] For consistency during the design change, all descriptors that have Dynamic will be considered to have an NbtName ("" 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)
[x] Make @NbtName work on any serializable type
A lot of the codebase assumes it's only used on conpounds/classes, so a lot of (related/unrelated) tests fail when broadening them to any type. Will do with care and comb through the code to check everything over.
[x] Make the new NbtNamed class serializable. Done after implementing it as an encode/decode representation because those will be necessary for testing its serialization
[x] Change buildNbtCompound(name) and buildNbtList(name) functions to return NbtNamed
[x] Change @NbtName to only nest under the name for the root value
Since the name will eventually only apply to the root value
[x] Remove the single-entry-root-compound name representation when encoding to NbtTags, binary, and snbt
[ ] @NbtName docs, which says it instructs the serialization to nest within an NBT compound so it's named
[ ] JavaNetwork docs: "Serializes unnamed NbtTags for use in network packets"
can remove mention of "unnamed", since there is no longer a difference in behavior with this design. (It was special because it didn't use an outer nbt compound for the internal representation, but now that's the way they all work)
[ ] Readme examples
[x] Make all serializable types have an NBT name, defaulting to an empty name if not marked with @NbtName
[ ] lenientNbtName configuration option, and name validation
Apply to empty-named JavaNetwork, which gracefully discards the name currently
With some variants being named, and with some having nullable roots, it doesn't make sense for all the variants to share the Nbt class. Requiring that they all have the same encodeToNbtTag() is forcing an abstraction. In reality, they are all (slightly) different formats, so should each be its own NbtFormat implementation (with all the same binary serialization methods, but different in-memory NbtTag serialization methods)
[ ] Additional in-memory NbtFormat providing encodeTo/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 for NbtTransformingSerializer so serializer's using it aren't unnecessarily limited by a specific NBT format.
Ayfri
commented
8 hours ago
See #29
Tasks:
NbtFormatBuilderinterfaceparameterizedNbtFormat()testing functionlistOf(NbtList, NbtByteArray)is inferred asList<Any>instead ofList<NbtTag>Byte/Int/LongArrays (see here)serializeris an instance of*ArraySerializer@NbtNamedto@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.nbtIntencodeTo/decodeFromNamedNbtTag()functions, so tests have a way to check against the serialized representationNbtName.Dynamicthat disables root name validation for a type (and later allows name to be serialized dynamically with encoder/decoder functions)@NbtName.Dynamicwhen delegating to another dynamic serializerDynamicwill be considered to have anNbtName(""by default). As opposed to requiring@NbtNameor not being named until the name is dynamically encoded, since all types will eventually be implicitly NbtNamed anyway)@NbtNamework on any serializable typeNbtNamedclass 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@NbtNameto only nest under the name for the root value@NbtNamedocs, which says it instructs the serialization to nest within an NBT compound so it's namedJavaNetworkdocs: "Serializes unnamed NbtTags for use in network packets"@NbtNamelenientNbtNameconfiguration option, and name validationJavaNbt,JavaNetworkNbt(val protocolVersion), etc.)Nbtclass. Requiring that they all have the sameencodeToNbtTag()is forcing an abstraction. In reality, they are all (slightly) different formats, so should each be its ownNbtFormatimplementation (with all the same binary serialization methods, but different in-memoryNbtTagserialization methods)NbtFormatprovidingencodeTo/decodeFromNbtTagwith 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 forNbtTransformingSerializerso serializer's using it aren't unnecessarily limited by a specific NBT format.