Extensible vanilla enums
YanisBft opened this issue ยท 9 comments
It would be really cool to make vanilla enums extensible, so we can easily add new rarity tiers, banner patterns or enchantment target types for example.
This wouldn't work, we aren't trying to replicate forge in anyway here. Having extensible enums opens up a pandoras box of issues including adding states which can't be normally reached in switch cases.
Also liach mentioned cases where the abstract methods become an issue.
Banner pattern are actually doable but it requires the nuclear option of replacing banners.
Though we need to remember this deenumization is going to be an absolutely painful thing to do since it would require rewriting some subsystems of the game.
Yeah, I dont think enum extending is great idea. Mojang have moved most commonly used things to interfaces.
In cases where its still an enum fabric api should provide a common api. This will need looking into on a case by case basis.
This is potentially doable, but as others have mentioned, it would be a massive undertaking and prone to issues.
We would have to:
- Add an interface to the current enum class
- Replace all usages of that class in the game with our interface
- Replace switch statements with something else
- Replace enum names with a registry
- Figure out something to do about ordinals
Replace all usages of that class in the game with our interface
This is no good for mods which don't use fabric API. Mods are excluded from the transformer class loader.
Replace all usages of that class in the game with our interface
This is no good for mods which don't use fabric API. Mods are excluded from the transformer class loader.
Ideally we would make an overloading you statically invoke, but we would redirect the regular enum methods to our overloadings.
Replace all usages of that class in the game with our interface
This is no good for mods which don't use fabric API. Mods are excluded from the transformer class loader.
Ouch. Indeed.
Replace all usages of that class in the game with our interface
This is no good for mods which don't use fabric API. Mods are excluded from the transformer class loader.
Fabric Loader transforms mod classes for environment stripping, so class transformation is already possible with respect to mods. This is not an argument for any approach, just stating that this is not a blocker.
There are problems with ordinals/names (with different sets of mods ran), jvm hotspot premature optimizations, and abstract methods to implement in enums. Vm stuff is easily fixed with asm, but ordinal/name inconsistency is a real problem, and don't think anyone has tried to extend enums with abstract methods yet.