| AvailableEnchantmentRegistry: reject non-string tags
fixes https://crash.pmmp.io/view/12627328
| 1 年前 |
| Fix PHPStan errors on PHP 8.5
| 3 个月前 |
| Use 'enchanting' terminology
'enchant' just didn't feel right, being a verb.
All these things pertain to the act of enchanting.
This is now also consistent with CraftingTransaction etc. The ship already sailed on EnchantInventory, which will have to be renamed at a later datte. However, that was already inconsistent with 'enchanting table', so that's the odd one out here.
| 2 年前 |
| Enchantment: added @see tags to @deprecated methods
| 2 年前 |
| Use PHP-CS-Fixer to enforce file header presence
| 3 年前 |
| Use PHP-CS-Fixer to enforce file header presence
| 3 年前 |
| Change some weird constant names
| 2 年前 |
| Change some weird constant names
| 2 年前 |
| PHPStan 2.0 fixes
| 1 年前 |
| Change some weird constant names
| 2 年前 |
| ...
| 3 个月前 |
| Use PHP-CS-Fixer to enforce file header presence
| 3 年前 |
| Use PHP-CS-Fixer to enforce file header presence
| 3 年前 |
| Avoid dodgy array_flip hash building
the conventional way is using array_keys and array_fill_keys. Behaviour is more predictable & also avoids benevolent union fuckery from PHPStan.
| 1 年前 |
| Use PHP-CS-Fixer to enforce file header presence
| 3 年前 |
| Use PHP-CS-Fixer to enforce file header presence
| 3 年前 |
| Implement frost walker enchantment (#5497)
Co-authored-by: Dylan T. <dktapps@pmmp.io> | 1 年前 |
| 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 个月前 |