Explore high and low level APIs, and their interaction

[jonathanfine]

I've created a pull request so we can discuss the code here. I won't be working on it much, if at all, for a week or so. But I can join in with the discussions. I'm not actually intending to merge this branch into master. though.

This code works for me (running on the client on Ubuntu and the Minecraft server on my raspi).

What's interesting for me is the way in which the various pieces of code exert forces on each other. Things like If we want to make this nicer, we have to change that.

What's exciting for me is that it actually works, and I now have a programming environment for raspberry pi Minecraft which I'm more comfortable with me. There are of course quite a few itches to scratch. I hope you'll help me find them.

[doismellburning]

I was confused as to how you'd managed to open a PR not built by Travis, then I realised you'd opened with a merge conflict and it all made sense!

[dbrgn]

I took a look at the lowlevel API. While it is a nice piece of engineering, I find it too complex. There is a lot of use of dynamic features and runtime-patching that will cause tools like the Jedi autocompletion stop working. The benefit is not big, but the complexity increases (lots of patching, many factories and converting signature declarations into functions).

While it's cool that such dynamic things are possible, I'd stick with simple function declarations, inheritance and composition. It makes maintenance easier and contributions more likely.

I absolutely agree that the implementation I did based on the legacy API is not very robust yet (ATM practically no argument checking), but that's something that can easily be fixed.

(Again: I don't think your code is bad, it's not. I just have a different opinion of what the API and the implementation should look like. Let the majority decide! :))

Any other opinions?

[doismellburning]

While it is a nice piece of engineering, I find it too complex. There is a lot of use of dynamic features and runtime-patching that will cause tools like the Jedi autocompletion stop working. The benefit is not big, but the complexity increases (lots of patching, many factories and converting signature declarations into functions).

+1

While it's cool that such dynamic things are possible, I'd stick with simple function declarations, inheritance and composition. It makes maintenance easier and contributions more likely.

+1