Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP]Interface mixins #74

Closed

Conversation

BenLewis-Seequent
Copy link
Contributor

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

@Mixin(IInventory.class)
public abstract class MixinInventory implements IInventory{

    private String name;

    public int size() {
        return this.getSizeInventory();
    }
}

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.

@Mumfrey
Copy link
Member

Mumfrey commented Oct 24, 2015

Sorry but you absolutely cannot implement this this way, I already explained to blood that there are problems with implementing this. Naïve approaches for debugging features which will never be used in production are perfectly fine, but if we throw naïve implementations out into the live forge ecosystem then it'll get torn to pieces. I can't stress enough how much time and effort has gone into not breaking every other mod in existence, which is difficult because some of them do some really stupid things. Something like this needs incredibly delicate handling and this just isn't it, sorry.

I already told blood I would look into a way to make this possible so I'm not sure why he requested this. Please run any new features by me before diving in.

@Mumfrey Mumfrey closed this Oct 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants