Data handling (central storage) #7
Description
A central object for a player could store data, as well as configurations (if set per player), all by check types. The problem would be how to fetch those efficiently and as type-safe as possible.
A getData(CheckType) method would likely have to return an Object. In the context of overriding checks of the same type it might not be fun to have to check what object is returned (not sure we allow such anyway, but it might be needed for backwards compatibility in some cases).
Making the method return "the desired" type will probably demand passing a class or similar in order to be able to check and return null or invoke a registered factory-method or return an actually present object.
We could consider having getData(CheckType) as the "slow method" for such as command use rather, while we maintain a getData(Class) or similar for "fast" access, which then returns the desired kind of thing, depending on registration. Of course this does not do recursive checking, it is meant for direct lookup.
After all it is still open how to do the contract for data / configs within a central player data object: Unique classes for differing check types? Allow storing multiple classes per check type? Register arbitrary object factories and classes for a check type and receive an integer id and/or a fast-access object to use for getting data fast later, something like "DataHolder getFastAccess(CheckType checkType, Class dataType)"?
The DataHolder would be for storing it during runtime, raising the problem of what happens on data removal or adding a new component or removing one such that the factories have to change (could provide events + setting the factories to null-factories on unregistration, it would probably be advanced user anyway.).
Should make example implementations / interfaces, probably...