subclasses of type classes

[Variadicism-zz]

Because enums are final, they can't use inheritance. That means if we want to have subclasses of "type" classes, e.g. if we want MobType as a subclass of EntityType, we will have to do something different. As you may have noticed, I made a separate branch on the repo for an experimental code reworking where I am attempting to see if I can redo the system as described in option 2. (Our current code on the master branch leans toward option 1.)

So, we have a couple options here:

• 1. We can have no subclasses of types, e.g. we would only have EntityType and no MobType classes or anything like that.
  • Advantages:
  • It would require the least amount of work from us of the three options. We can use plain old straightforward enums with no craziness needed.
  • It would avoid potential debate and confusion over classifications (e.g. what counts as a "mob"?; there are differing definitions).
  • Disadvantages:
  • Plugin authors would have to sort through the entire list of blocks or entities or whatever else, which can be a little overwhelming and confusing and could make people say things like "All I want to do is make a Swiftness Potion!"; a PotionType that inherits from ItemType could make things much easier.
  • Without Java 8's default and static methods in interfaces, we would have to implement some utilities for each class individually like getID(), getData(), getSiblings(), etc. that we wouldn't need to reimplement in option #2.
• 2. We can try to make a pseudo-enum system using public static final instances like enum values, our own implementations of values(), etc.
  • Advantages:
  • If we used inheritance with the superclasses, e.g. EntityType as a superclass of MobType, MobType can inherit all the utilities of EntityType without having to reimplement them all like we would have to in option #3.
  • If we used inheritance with some abstract classes like IDedType, we could implement instance methods and variables in the super classes with ease and make "helper" functions to minimize the effort of implementing static functions.
• 3. We can try to make a pseudo-inheritance system with enums where each enum type has a "parent" type and a "child" type (one of which can be null). Going back to the MobType example, each MobType would have to refer to a corresponding parent EntityType that it would inherit many properties from; conversely, each EntityType might have a child type that could be a MobType or of another type that "extends" EntityType.
  • Advantages:
  • We can keep using plain enums, which are efficient and powerful and much less syntactically tedious compared to option #2.
  • It would make the code look nice (though repetitive and tedious).
  • Disadvantages:
  • We could have to re-implement all utilities for each subtype to simply refer to the super type's name utilities, e.g. LivingEntityType.canBurn() would have to be re-written even though EntityType.canBurn() exists; that's going to get tedious fast and it means adding a new utility method to one class will take a long time because we have to add it to all the other classes.
  • These parent-child relationships are complex and may throw plugin authors off; for example, the parent of a MobType will probably not be an EntityType; there will likely be other type levels between MobType and EntityType like LivingEntityType.
  • Parents and children will have to be coded for each and every enum value in each type, which is going to get tedious fast. I had the thought that we could name parents and children with the same names, then when one enum type is initialized, we can just have it locate its parent in the values() of its direct super type using the enum standard name() method.
  • It could be difficult to add in new levels to this hierarchy because we could have to change all the parents of sub types and all the children of the super types to point to the new types. If we do what I mentioned above, we would actually only have to change which values() is called in the constructor, e.g. if we had EntityTypes as direct parents MobTypes and we decided to add in LivingEntityType in between them, we could just change the EntityType constructor to use LivingEntity.values() to find its child instead of MobType.values(); similarly, MobType's constructor portion that locates the parent type could simply be changed from EntityType.values() to LivingEntityType.values().

If only we could use Java 8....

Anyway, I'm not going to express opinion on this one yet; I'm going to let you guys reply first.

[Variadicism-zz]

It looks like we'll be going with option 2.