List of proposals for v2 about hephaistos

[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 088ebf6

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.