Skip to content

Instantly share code, notes, and snippets.

@anuar2k
Created January 13, 2018 14:47
Show Gist options
  • Save anuar2k/1778bd3a3cd34c4385f08450f53fecdd to your computer and use it in GitHub Desktop.
Save anuar2k/1778bd3a3cd34c4385f08450f53fecdd to your computer and use it in GitHub Desktop.

There is several things that I want to mention as the comparison of old and new block families

  1. Usage of the new implementation is much simpler. You do not have to create a factory for them.
  2. Marking possible sections as a java annotation is better - previously, you had to override the getSectonNames method to list all sections possible (I was unsure if I hade to do it or now - currently, this method doesn't even exist because its redundant) - now, when sections are set in an annotation, it's easier to differentiate what sections are for and what do they mean.
  3. Support for freeform is also marked with an annotation now. In general, the concept of "basic settings" of the family as annotations is very cool and fun to use.
  4. Using new block families implementation in my situation reduced the SLOC count by a HALF.
  5. You don't need to pass WorldProvider and BlockEntityManager as getBlockForPlacement's argument - the creator of a family can now decide himself if he needs access to these systems (the creator of the family can get access to these in his family directly). Previous methods forced the user to retrieve worldProvider and blockEntityManager if they wanted to use family's methods also in their own systems.

Improvements?

Maybe the AbstractBlockFamily should retrieve family's URI and categories from BlockFamilyDefinition automatically on super constructor call, instead of forcing the developer who's extending AbstractBlockFamily to call super.setBlockUri() and super.setCategory() himself. It's something that is by default anyways just retrieved from BlockFamilyDefinition and not modified by the creator of the new family. And it's something the creator of new family might forget about.

@anuar2k
Copy link
Author

anuar2k commented Jan 13, 2018

Oh, and it needs to be clearly stated if adding the module's name which adds a new family is needed in the @RegisterBlockFamily annotation. Because I've already seen two ways of doing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment