[Feature] Add API to query type of PersistentDataContainer value

[Keksnet]

Hi,
this PR adds a method that makes it possible to query the data type of a specific value inside a persistent data container.
With this method it will be possible to read a value without knowing the exact type of the value you are trying to read.
This is useful for migrating the data type of a value to another one or for a library that sits on top of Paper and does not know the type by design.
It enables further tools like editors for the persistent data container to be developed without the need to check every available data type or using a nbt API.

I have tested the method using the test-plugin and can provide my testing code if necessary.

This API in its current form is not able to correctly determine the data type of nested lists but I'm already trying to fix this issue. Already fixed.

Any question or feedback is welcome. 🙂

[Keksnet]

Detection of nested lists is now fixed.

[lynxplay]

I am not much of a fan of such an method, definitely not under the proposed method name at least.

Type information is not encoded. A plugin inserting a value using PersistentDataType A is not guaranteed to receive said data type when querying the PDC#getType().
This is already true for every plugin maintained type but even spreads to API exposed types like BOOLEAN.

Maybe PDCV#estimatePrimitiveDataType(Key) could work? With a large amount of notice in the javadocs.

[Keksnet]

@lynxplay I totally missed the possibility of plugin-specific data types. I renamed the method and edited the javadocs. This should hopefully reflect that this method is essentially only estimating the data type based on the underlying nbt tag.
I also changed the type of the key argument from NamespacedKey to Key (from adventure). This should make it easier to integrate with existing adventure code and no require a remapping from Key -> NamespacedKey.
This is not a problem for any code, as NamespacedKey implements Key.

[Leguan16]

I personally don't really like the name estimatePrimitiveDataType. What do you all think about getStorageType, as in "the type the PDC is stored in"?

[Keksnet]

@Leguan16 I personally think the storage type thing is too abstract. I would maybe suggest getNbtTagType. I'm worried that this name would be inaccurate as there is nothing that says, that pdc data will always be stored inside nbt tags.

[Leguan16]

I would maybe suggest getNbtTagType

The issue with this name is that there is no concept of NBT in the API I think. So it could be a confusing name.

[Keksnet]

getStorageType would be fine if I add an explanation to the javadocs to explain what the storage type is. I think it would cause confusion otherwise. It would be smart to not put some implementation detail like nbt into the name.

[lynxplay]

@Leguan16 the point of "primitive" here was that the persistent data type interface already has the concept of a complex and a primitive type. We can fight over the verb estimate but "storage" vs "primitive" seems like an easy choice in my head.

[Leguan16]

what about getPrimitiveStorageType?

Since I assume you want the primitive to be apart of the method name, and we are getting the type the PDC is actually stored in i think its a good name.

[Machine-Maker]

I think primitive is a good word to use. That is what we call it in when you are implementing PersistentDataType for a custom converter to your own type, we call the base type a getPrimitiveType.

[Keksnet]

I have renamed the method to getPrimitiveStorageType and added to the documentation that the returned type is estimated based on the "primitive type that is stored" as explation for the storage type.
Would that be fine for everyone involved here?