Skip to content
This repository has been archived by the owner on Sep 20, 2024. It is now read-only.

List of proposals for v2 #7

Open
9 of 11 tasks
BomBardyGamer opened this issue Jun 25, 2021 · 5 comments
Open
9 of 11 tasks

List of proposals for v2 #7

BomBardyGamer opened this issue Jun 25, 2021 · 5 comments

Comments

@BomBardyGamer
Copy link

BomBardyGamer commented Jun 25, 2021

@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:

  • Make NBTEnd an object, since it only needs one instance and doesn't ever need to be copied.
  • 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.
  • Add ONE and ZERO constants for NBTByte, which are both immutable with backing values of 1 and 0 respectively (for easier boolean conversions).
  • 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.
  • Add constructors to NBTList and NBTCompound that accept lists and maps respectively, for easier construction.
  • 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.
  • 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?
  • Support initialising the NBTReader and NBTWriter with a Path object as well as with a File.
  • 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
Copy link

KrystilizeNevaDies commented Jun 25, 2021

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
Copy link

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
Copy link
Collaborator

jglrxavpok commented Jun 26, 2021

@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
Copy link
Author

BomBardyGamer commented Jun 26, 2021

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
Copy link
Collaborator

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

jglrxavpok added a commit to Project-Cepi/Hephaistos that referenced this issue Aug 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants