[NO MERGE] Contextual Data API #2496
Conversation
|
|
||
| Iterable<DataPerspective> perceives(); | ||
|
|
||
| ValueContainer getDataPerception(DataPerspective perspective); |
There was a problem hiding this comment.
Should just be dataPerception(...) no?
| import org.checkerframework.checker.nullness.qual.Nullable; | ||
| import org.spongepowered.api.data.value.Value; | ||
|
|
||
| public interface DataPerspectiveResolver<V extends Value<E>, E> { |
There was a problem hiding this comment.
Is this interface meant to be implemented? (DataRegistration below gives that impression).
If so, maybe it is best to make this abstract? I do not like a method that returns the key that isn't enforced to always return the same key (the instance could change).
There was a problem hiding this comment.
Yes, this is at the moment required to light up contextual data, otherwise we refuse to apply the data. I followed the same style we use for DataProvider already, that also has getter for the key.
But it might be more beneficial to try to intergrade this whole concept to be part of DataProvider to make them always be contextual aware, but that then touches a lot of core data API surface area.
There was a problem hiding this comment.
it's up to you as it's a commitment on your part but if you are up to it, I think this is a spot where we go all in and make DataProvider and the data API as a whole contextual aware. It was always meant to be, no one sat down to do it was always the issue.
Until now :).
Sponge | SpongeAPI
Open questions?
offerSingleto the data perspective and the base entity already has elements. Append? Create new list with just that single item?Value<Integer>could have addition, multiplication, etc.