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.
As requested by @bloodmc and in issue #69, this PR implements interface mixins, mixins that target a class implementing the declared class instead of the declared class itself.
This is currently a simply solution and doesn't take into account more complex situation that can occur which must be worked out before this is merged.
This behaviour works for all mixin targets that are interfaces, so one mixin can target both interfaces and classes.
Example
Which mixs the method/field into the top most implementations of IInventory(classes who superclass doesn't implement IIventory). Which means TileEntityLockable gets this mixin mixed in where as TileEntityChest doesn't as it extends TileEntityLockable.
Note it must extend the interface you want(directly or indirectly) to access the methods in the interface. Shadowing doesn't work as it targets the implementation not the interface and if the implementation is abstract then it will fail.
Implementation
MixinTransformer/MixinConfig/MixinInfo keep track of the mixins that are interface mixins and the mapping between the interfaces and the mixins. When a class is transformed it first does a depth-first search to find all interface mixins by loading each superinterface and superclass and calculating their interface mixins. Note this only slightly changes the order of the classloading of the interfaces and superclass as they would immediately loading anyways after it finished transforming and I have not seen a problem.