Enums limit plugins' ability to create custom stuff with existing PM core code

[Dylan T.]

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:

• create custom banner pattern types (I'm not sure this is actually possible with Minecraft itself, but ok)
• create custom variants of some block types, such as:
  • any wood-like block (WoodType)
  • leaves
  • saplings
  • dirt
  • mob heads
  • music discs
  • furnaces
• create custom variants of some item types, such as:
  • tiered tools
  • boats
  • potions
  • suspicious stew
  • medicine

The element types of these enums should be unbound from the enums themselves. This model has been used in various places:

• VanillaBlocks
• VanillaItems
• VanillaEffects
• VanillaEnchantments
• VanillaArmorMaterials

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, as EnumTrait 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.