René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"RFC: Entrypoint reworks","articleBody":"Patchwork's current entrypoint system needs a rework. I've drafted up some ideas on what that might look like. Please tell me what you think about them!\r\n\r\n## Introduction\r\n\r\nOne of the future refactors I have in mind for Patchwork Patcher is to rework the entrypoint system. However, Patchwork API (more specifically, patchwork-dispatcher) would need to be modified to support and use these entrypoints, which is why I'm posting this here. The current single, unsided entrypoint system introduced back in September 2019 is showing its age, and has a few definite limitations:\r\n\r\n* No support for getting the mod instance\r\n* No (proper) support for sided automatic event bus subscribers (excluding using something like DistExecutor, which is arguably a hack)\r\n* Classes containing `@ObjectHolder` and `@CapabilityInject` annotations are potentially loaded too early (during mod construction rather than after registry creation)\r\n\r\nWhen implementing these entrypoints in Patcher, I intend on adding the methods to existing classes, and then using method references, as opposed to generating separate entrypoint classes.\r\n\r\nAs such, I propose adding a few different entrypoints:\r\n\r\n## patchwork:mod_instance\r\n\r\nA marker entrypoint to denote classes originally annotated with `@Mod`. Used get the mod instance. This would be an alternate approach to solve the same problem as https://github.com/PatchworkMC/patchwork-patcher/issues/53. As a side effect, fabric-loader will construct the mod for us when we query the entrypoint, which is convenient.\r\n\r\n```java\r\npublic interface ModInstance {\r\n    // Loader has a feature similar to this, but since it doesn't support having multiple modids for the same jar\r\n    /// this is still needed. - Glitch\r\n    String getModId();\r\n}\r\n```\r\n\r\n## patchwork:common_automatic_subscribers\r\n\r\nRegister unsided `@EventBusSubscriber`s. Uses `ModInitializer`. Method name used in method references: `patchwork$onInitialize`. TODO: Should the automatic subscriber entrypoints use a custom interface that e.g. provides the MOD / FORGE bus in the entrypoint method?\r\n\r\n## patchwork:client_automatic_subscribers\r\n\r\nRegister client-only `@EventBusSubscriber`s. Uses `ClientModInitializer`. Method name used in method references: `patchwork$onInitializeClient`.\r\n\r\n## patchwork:server_automatic_subscribers\r\n\r\nRegister dedicated-server-only `@EventBusSubscriber`s. Uses `DedicatedServerModInitializer`. Method name used in method references: `patchwork$onInitializeServer`.\r\n\r\n## patchwork:object_holders\r\n\r\nRegister all object holders with the ObjectHolderRegistry here. Fired after new registries have been created, but before registry events have been dispatched.\r\n\r\n```java\r\npublic interface ObjectHolderInitializer {\r\n\tvoid registerObjectHolders(ObjectHolderRegistry registry);\r\n}\r\n```\r\n\r\n## patchwork:capability_injections\r\n\r\nBasically the same thing as `patchwork:register_object_holders` (and fired right afterwards) but for `@CapabilityInject`.\r\n\r\n```java\r\npublic interface CapabilityInjectionInitializer {\r\n\tvoid registerCapabilityInjections(CapabilityManager manager);\r\n}\r\n```","author":{"url":"https://github.com/coderbot16","@type":"Person","name":"coderbot16"},"datePublished":"2020-07-11T04:24:35.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/119/patchwork-api/issues/119"}