Enums limit plugins' ability to create custom stuff with existing PM core code #6292
Labels
BC break
Breaks API compatibility
Category: API
Related to the plugin API
Type: Enhancement
Contributes features or other improvements to PocketMine-MP
Milestone
Description
Since PM4, we've been using enums to lock down some of the invalid stuff that plugins were doing with the API and causing crashes.
However, in some cases, these changes have caused problems for plugins.
Doing the following things in PM4+ properly (without reflection) requires re-implementing and/or copy-pasting parts of the core code:
The element types of these enums should be unbound from the enums themselves. This model has been used in various places:
While these registries cannot be directly modified (which isn't going to change), the element types of the registries (Block, Item, Effect, Enchantment, ArmorMaterial) can be instantiated without going through the registry, making it possible to create custom types of these things. This is not possible with enums, whose elements can only be created by the enum class itself.
Justification
Restoring customization ability lost in the PM4 overhaul
Caveats
It is worth mentioning that
RegistryTrait
invocations are slower than their enum counterparts.In addition, registries are uglier, more inconvenient to configure, and require more code.
Alternative methods
Plugins used to be able to use reflection to hack new elements into
EnumTrait
-using enums. However, this is no longer possible, asEnumTrait
has been superseded by native PHP 8.1 enums, which cannot be altered by reflection.In any case, this is a bad workaround that shouldn't be used.
The text was updated successfully, but these errors were encountered: