What do you exactly mean by you don't like using interfaces?
As in, overriding a lifecycle interface in which you have to create/setup your mod?
The different aspects of Minecraft needed different forms of implementation for modding.
Yes, blocks worked through implementing abstract classes which gave base behavior, but event interception worked through annotations. So I don't fully see what your argument is in this?
I expect we will have different approaches to different aspects of the game.
(E.g.: an Entity base class for villages / monsters etc).
On a sidenote, Reflections solves 95% of the work of scanning the classpath.
We can remove the burden of implementation from the coder with regards to registering classes and have this done automatically through discovery.
I dislike using @ annotations, it seems weird to me and I find overriding functions of a class looks more appropriate, not sure why.
I'm aware of how minecraft modding worked, having used both forge and bukkit. I appreciated that bukkit used the @ in that instance as it meant you just had to make a function with the event you wanted to listen to as the input, because they did it in a nice way.
Reflections are likely to break given that it's still InDev, though I agree they are a suitable method once the game hits a more stable version. Thank god Ray doesn't obfuscate.
He said he has no idea right now about mod support, and he MIGHT release source code. Just putting that out there.
I'm pretty sure he wants to release the source code *at some point* in the future, just to make some people's lives easier (i.e. ours). I'd love for official mod support to exist, and would also love to work on that mod support and give modders every last thing they need.
