stable

GGitHubFully generated registry accessor classes (#6905)

9f9d5d78创建于 2025年12月20日历史提交

文件	最后提交记录	最后更新时间
doxygen.conf	Fully generated registry accessor classes (#6905) This is a new take on RegistryTrait. While this is a major change internally, outwardly it should work exactly the same for the vast majority of plugins. However, any plugins that were using reflection to mess with Vanilla* (e.g. to override blocks) will break due to internal design changes. Compared to RegistryTrait, this has various advantages: - Performance - simple (non-cloning) registry accessors such as VanillaEffects are over 300% faster - cloning registry accessors like VanillaItems are 30-40% faster - registry accessors are now regular functions instead of using __callStatic(), meaning that JIT and Opcache optimizations can improve their performance even further - Robustness - while the member values of registries can still be tampered with via reflection, their types are now strictly enforced, which forces plugins to use a class that matches the original type if they want to e.g. hack in a custom class for a block - plugins cannot add new registry cases via reflection, making it clear that these are not meant to be modified - Separation of gencode from source code: this makes it clearer to contributors which files are not to be touched - Doxygen can now understand VanillaBlocks et al and generate proper docs entries, since it didn't understand the @method tags used previously How it works: - A class extending RegistrySource is declared - Members are declared in setup() as before, using register() or registerDelayed() depending on the needs of the code - build/generate-registry-interface.php src generated - Generated classes with many functions and initialization logic are placed in the generated/ folder - When first accessed, the generated class invokes YourRegistrySource->setup() to get the values to assign to its internal members The main downside to this change is that the generated registry accessor class cannot have custom code added to it. This pattern was never used by PocketMine-MP, but grepPlugins reveals that plugin developers sometimes add custom utility functions to RegistryTrait-using classes, which is not possible with this new system. However, this seems like a small price to pay for the major improvements this system enables. Such functions can always be moved to a separate utility class. This might be revisited in the future if there's a demand for custom functions on the generated output class. This change also opens the potential for allowing proper overrides of blocks and items, since the gencode is able to enforce class types and ensure type compatibility with code using these functions. I'm not sure if this is something we'll actually allow, but it's a lot less work to safely allow it with this design than with the legacy RegistryTrait. RegistryTrait would have had to do manual type verification, while this design just works like normal code. There are some minor caveats with this approach, however. Since the accessor functions don't necessarily exist during setup() (as it may be called during codegen), anything that wants to access something via a generated registry interface must use registerDelayed() instead of register(). This is seen in a few places in VanillaItems where items need to reference VanillaBlocks. In this case, the type of the generated registry accessor is based on the return type of the closure given to registerDelayed(), instead of being taken directly from the value. This allows the gencode script to operate without fully initializing the registry, which would cause a circular dependency problem. TLDR: New registry system, much fast, big improve, many robust, very wow!	4 个月前
index.md	[ci skip] doxygen: link to devdoc.pmmp.io instead of the github repo	5 年前