List of proposals for v2

[BomBardyGamer]

@jglrxavpok told me to make an issue with these, for easier tracking, so here we are.

Here's the list of proposals I have for things in v2:

• [x] Make NBTEnd an object, since it only needs one instance and doesn't ever need to be copied.
• [x] Add an EMPTY constant for NBTCompound, which is an immutable compound with an empty backing map. Also add one for NBTList, which is an immutable list with elements of type TAG_End backed by an empty list.
• [x] Add ONE and ZERO constants for NBTByte, which are both immutable with backing values of 1 and 0 respectively (for easier boolean conversions).
• [x] Allow getting/setting booleans on compounds, with functions such as getBoolean/setBoolean.
• [ ] Add a new method for getting every type from a compound with a default value, and these methods should never return null. For example, getString("my_key", "my_default") would look for a string in the map with the key "my_key", or else it would return "my_default" if no such value was found.
• [x] Add constructors to NBTList and NBTCompound that accept lists and maps respectively, for easier construction.
• [x] Expose the backing map of an NBTCompound and the backing list of an NBTList in some way, whether this be an immutable copy, or just the actual map itself.
• [ ] Possibly add a better way to read compound tags, instead of having to construct a new reader and then read and perform an unchecked cast.
• [x] Add support for ZLIB compression when reading/writing NBT data. For reference, Adventure does this by having a compression type pseudo enum with compress and decompress methods that are implemented in their respective types, perhaps you could do something similar?
• [x] Support initialising the NBTReader and NBTWriter with a Path object as well as with a File.
• [x] Support for calls like getOrElse and getOrNull on an NBTList. Would probably be better if NBTList just implemented List<Tag> instead of Iterable<Tag>.

Hope this helps you keep track of everything!

[KrystilizeNevaDies]

Some static (companion object) methods for the NBTReader would also be nice e.g.

NBTReader.parseString(nbtString)

Possibly add a better way to read compound tags, instead of having to construct a new reader and then read and perform an unchecked cast.

A better way could be returning a generic like <T extends NBT> so that implicit casting could be used.

[Protonull]

Just a passerby from the Minestom Discord. It might be worth sealing these NBT classes. It's still a preview feature, but if you're thinking about managing instances to that extent, it's not a stretch to suggest managing classes too.

[jglrxavpok]

@BomBardyGamer

Expose the backing map of an NBTCompound and the backing list of an NBTList in some way, whether this be an immutable copy, or just the actual map itself. Make NBTEnd an object, since it only needs one instance and doesn't ever need to be copied.

Done in 088ebf68cf9c7b5e9a4b91ee1ca4479a5c933045

Add a new method for getting every type from a compound with a default value, and these methods should never return null. For example, getString("my_key", "my_default") would look for a string in the map with the key "my_key", or else it would return "my_default" if no such value was found.

Already present in v2: getOrDefault

@Protonull

Just a passerby from the Minestom Discord. It might be worth sealing these NBT classes. It's still a preview feature, but if you're thinking about managing instances to that extent, it's not a stretch to suggest managing classes too.

Kotlin already has sealed classes, but Hephaistos cannot use it because mutable versions of tag (in v2) inherit both from MutableNBT and ImmutableNBT (two interfaces). Kotlin (like JVM-based languages) does not allow multiple superclasses, so sealing the base MutableNBT and ImmutableNBT is sadly not possible with the current state of the library. We'll see if/when the proposal is accepted inside Java, maybe Kotlin will add sealed interfaces too.

[BomBardyGamer]

As of Kotlin 1.5, Kotlin now has sealed interfaces FYI.

And sealed class/interface support has been extended, so now any members declared in the same package can participate in the heirachy, rather than just in the same class

[jglrxavpok]

I was not aware about sealed interfaces in Kotlin 1.5, I'll have to see if it can apply.