Check capability before unchecked cast #32
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #30, #31, #33, and ferriarnus/Unidentified-Enchantments#16.
The main way capabilities function are by trusting the capability itself with its own type. The type you choose for the capability is cast to
Capability<C>
upon registration, but you are nevertheless in control of the entire capability and its usage yourself, as long as you implement the required interfaces at minimum. Therefore, doing reckless unchecked casting on overridinggetCapability()
is going to cause problems because of the way capabilities work.Your capabilities look good and work great, but make sure to watch for little nuances like these. There's also a bit of repetitive code between the Quiver and Scabbard capabilities that could be better isolated into a single class/interface file (for example, I made
CapabilityProvider
andIPersistentCapability
in ForageCraft 1.17 for this purpose). Also note the usage ofCapabilityManager.get()
in order to get active capabilities from the game, rather than the now deleted@CapabilityInject
annotation.