Draft
Conversation
this allows us to reference registry members with dynamic enum cases, which has a lot of potential applications. this enables us to keep the blocks as unique types, but with some of the power of dynamic state properties. this is a rough initial proof of concept; it will need to be improved for further integration.
…oaded-registry-members
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Blocks & items like wooden things might have different properties per wood type, so they're implemented as fully separate flattened blocks, like in vanilla.
However, we can avoid a lot of shitty code by auto-generating some simple functions that match an enum case to a block of a certain wood type.
The PR demonstrates this with
VanillaBlocks::SIGN(WoodType $case) : FloorSignandVanillaItems::SIGN(WoodType $case) : ItemBlockWallOrFloor. A significant amount of boilerplate code is able to be deleted because of the additions of these simple functions.This could be extended to all other wood-like blocks, but this PR mainly focused on a proof-of-concept to establish feasibility.
Future scope
mb_strtolower($t->name) . "_sign")between overloaded member and actual registrationVanillaBlockMappings, which currently has to do a horrendous amount of this sort of copy pasta to implement each wood typeBackwards compatibility
Fully backwards compatible
Tests
Tests are green. The code is used in the core, so it's established that it's working.