[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.
See #29
Tasks:
NbtFormatBuilder
interfaceparameterizedNbtFormat()
testing functionlistOf(NbtList, NbtByteArray)
is inferred asList<Any>
instead ofList<NbtTag>
Byte
/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.