There is several things that I want to mention as the comparison of old and new block families
- Usage of the new implementation is much simpler. You do not have to create a factory for them.
- 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. - 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.
- Using new block families implementation in my situation reduced the SLOC count by a HALF.
- You don't need to pass
WorldProvider
andBlockEntityManager
asgetBlockForPlacement
'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 retrieveworldProvider
andblockEntityManager
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.
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.