| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
|
||
| Iterable<DataPerspective> perceives(); | ||
|
|
||
| ValueContainer getDataPerception(DataPerspective perspective); |
There was a problem hiding this comment.
Should just be dataPerception(...) no?
Sorry, something went wrong.
| 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).
Sorry, something went wrong.
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.
Sorry, something went wrong.
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 :).
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Sponge | SpongeAPI
Open questions?