Fabric Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Exposing Added Fields ======

Mixin allows developers to add new fields and methods to a target class, this can be useful for operations internal to the Mixin class, but you may want to expose your added members to the rest of your project. In order to do this, you can use "duck" interfaces. That is to say a non-Mixin interface implemented into the target class via a Mixin, which adds methods that expose added members to the rest of a codebase.

===== Using a Duck Interface =====

==== Hypothetical Scenario ====

For our example situation, we'll use 1.21.10 with Mojang Mappings. We will add and expose fields to the Zombie class for a hypothetical combo mechanic we'd want to be able to interact with outside of the Mixin.

==== Adding the Field ====

<code java>
@Mixin(Zombie.class)
abstract class ZombieExampleMixin {

    @Unique
    private int modid$comboCount;
    
    @Inject(method = "<init>*", at = @At("TAIL"))
    private void populateField() {
        modid$comboCount = 0;
    }

    @Inject(method = "tick", at = @At("TAIL"))
    private void doSomethingWithCombos(CallbackInfo ci) {
        /* ... */
    }

}
</code>

This field is normally entirely inaccessible, and we can't just make our Mixin class public and get the field that way, because our Mixin class itself won't exist at runtime. However, if we use an interface that will exist at runtime, and implement it into the target class via our Mixin, we'll be able to use the fields via the interface.

:?: We use ''@Unique'' to ensure that we do not clash with any other mods' added fields in the same class, and prefix the field with our mod id in order to also make it easier to find which mod is involved in issues pertaining to added fields in logs.

==== Creating the Interface ====

A common naming convention for "duck" interfaces is ''TargetClassAccess'', we'll use it here:

<code java>
public interface ZombieAccess {

    int modid$getComboHits();

    void modid$setComboHits(int newCount);

}
</code>

This effectively acts as an exposed getter and setter for our example's sake, but any number of methods can be added this way. Since the methods will be added to the target class by our implementation, we should also add ''modid$'' here to avoid clashing with other mods.

==== Implementing the Interface ====

<code java>
@Mixin(Zombie.class)
abstract class ZombieExampleMixin implements ZombieAccess {

    @Unique
    private int modid$comboCount;

    @Override
    public int modid$getComboHits() {
        return modid$comboCount;
    }

    @Override
    public void modid$setComboHits(int newCount) {
        modid$comboCount = newCount;
    }

    @Inject(method = "<init>*", at = @At("TAIL"))
    private void populateField() {
        modid$comboCount = 0;
    }


    @Inject(method = "tick", at = @At("TAIL"))
    private void doSomethingWithCombos(CallbackInfo ci) {
        /* ... */
    }

}
</code>

==== Using the Interface ====

The compiler will allow us to cast instances of the ''Zombie'' class to our interface without causing issues, and since the interface will be implemented by Mixin at runtime, it won't cause issues at runtime either:

<code java>
public class ExampleClass {

    public static void holder(Zombie zombie) {
        int currentCombo = ((ZombieAccess) zombie).modid$getComboHits();
        ((ZombieAccess) zombie).modid$setComboHits(currentCombo + 1);
    }

}
</code>