Differences

This shows you the differences between two versions of the page.

--- tutorial:mixin_your_first_mixin [2025/10/17 10:49] – Push out of drafting gauntrecluse
+++ tutorial:mixin_your_first_mixin [2025/11/16 13:35] (current) – Minor fixes to try and simplify wordings and fix typos gauntrecluse
@@ Line 1: / Line 1: @@
-:!: //This page was recently pushed, and may still have inaccuracies or lacking in a few aspects. Feedback and improvements are greatly appreciated!//
 ====== Tutorial: Making your first Mixin ======
 ===== Preamble =====
-This is meant to be complementary to the [[tutorial:mixin_introduction|Introduction to Mixins]] page, it is not required but highly recommended to read it before this tutorial. This tutorial intends to hold a newcomer's hand through each step of creating a very elementary Mixin. This intends to create familiarity with basic Mixin notions and syntax, thus lessening the esoteric appearance Mixins have during their initial learning curve.\\
+This is meant to be complementary to the [[tutorial:mixin_introduction|Introduction to Mixins]] page, it is not required but highly recommended to read it before this tutorial. This tutorial intends to hold a newcomer's hand through each step of creating a very elementary Mixin. This intends to create familiarity with basic Mixin notions and syntax, reducing how strange Mixins can seem during an initial learning curve.\\
 See [[tutorial:mixin_registration|Registering Mixins]] for setting up Mixins on a Fabric project if you intend to follow along with this.
@@ Line 28: / Line 26: @@
 </yarncode>
-It is conventional practice to name your Mixin classes the target class with ''Mixin'' appended as a suffix. Here, it would typically be named ''MinecraftServerMixin'' instead. This makes is very easy for someone who is looking through your project to know which Mixin classes have a given target. If you, for whatever reason, opt to not follow this convention, it is recommended to still name your Mixins after what they target in some way.
+It is conventional practice to name your Mixin classes the target class with ''Mixin'' appended as a suffix or prefix. Here, it would typically be named ''MinecraftServerMixin'' instead. This makes is very easy for someone who is looking through your project to know which Mixin classes have a given target. If you, for whatever reason, opt to not follow this convention, it is recommended to still name your Mixins after what they target or aim to modify.
-You'll notice we made the Mixin class ''abstract''. This is a best practice when mixing into a class, as it avoids an accidental instantiation of the class, and removes the burden of needing to implement methods that may break the Mixin when implementing and extending the target's superclasses and interfaces.
+You'll notice we made the Mixin class ''abstract''. This is a best practice when mixing into a class, as it avoids an accidental instantiation of the class, and removes the burden of needing to implement methods that may break the Mixin when implementing and extending the target's superclasses and interfaces. We've also not made it ''public'', this makes it package-private and is best-practice since Mixin classes shouldn't be accessed or instantiated outside of their specific packages.
 Accordingly, we will also add this to our ''mixins.json'' config file:
@@ Line 90: / Line 88: @@
     *  ''method = "<yarn method_3735>"'' narrows down the point of injection to within that target method
     * ''at = @At'' is used to specify what to look for in the targeted method(s)
-      * ''value = "HEAD"'' specifies that Mixin should try to inject at the very start of the method at the point of injection.
+      * ''value = "HEAD"'' specifies that Mixin should try to inject at the very start of the method as the point of injection.
 //Sidenote: one does not need to put ''value ='' if it is the only argument passed to ''@At'', e.g. ''@At("HEAD")'' is valid.//
@@ Line 129: / Line 127: @@
 </yarncode>
-The constructor is functionally irrelevant here, it's only there for the sake of extending without errors. One may notice that we didn't implement any methods, this is thanks to our class being abstract. Abstract classes do not need to implement methods from parents, allowing us to not have to handle all the overrides you would normally get.
+The constructor does not impact functionality, it's only there for the sake of extending without errors. Notice that we didn't implement any methods from the supers, this is thanks to our class being abstract. Abstract classes do not need to implement methods from parents, allowing us to not have to handle all the overrides you would normally get.
 ==== Debugging Mixins ====