Live data from Hacker News

The Minecraft API Is Now On Github

github.com

11–20 of 53 posts

Re: The Minecraft API Is Now On Github

#11
post #4
post #2

Is it just me, or is the only thing that the API currently supports banning?

He started working on it 3 hours ago

This is the real reason that Notch is working on 0x10c. He's hoping that along the way, he'll learn enough physics to develop time travel, so he can release code before he even begins development.

I tip my hat to him for his commitment to "release early, release often."

Re: The Minecraft API Is Now On Github

#12

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. On my machine that means it would end up being: /home/ajf/Projects/2012/Minecraft/Minecraft-API/src/main/java/net/minecraft/workbench/ Who on earth thought deeply nested directories for packages was a good idea?

Java has nothing to do with that. If you want to you can put everything in the default package (no nesting) or in a 1000 nested directory.

Java does not stop you from doing this:

Minecraft-API

    |- src

Re: The Minecraft API Is Now On Github

#13
post #5

Not much in here as of right now , so if you looking as to what can be done immediately there isn't much of anything. It is cool that this is being worked on in public. Honestly I don't know why this is a fresh project instead of just an official fork of Bukkit.

Besides the mentioned licensing-issues, Dinnerbone (the guy hired by Mojang, who used to work on Bukkit) – as well as others involved – has said that they like the opportunity to start fresh. Things, which was done one way in Bukkit, isn't necessary the best way and given the opportunity to do it better, it's not a hard choice.

Re: The Minecraft API Is Now On Github

#14

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. On my machine that means it would end up being: /home/ajf/Projects/2012/Minecraft/Minecraft-API/src/main/java/net/minecraft/workbench/ Who on earth thought deeply nested directories for packages was a good idea?

Java has nothing to do with that. If you want to you can put everything in the default package (no nesting) or in a 1000 nested directory. Java does not stop you from doing this: Minecraft-API |- src

So it's a choice between bad and worse?

Re: The Minecraft API Is Now On Github

#15
post #14

Earlier quoted context omitted.

Java has nothing to do with that. If you want to you can put everything in the default package (no nesting) or in a 1000 nested directory. Java does not stop you from doing this: Minecraft-API |- src

So it's a choice between bad and worse?

How else can it be done? If you want namespaces you can use them, if not you don't.

Re: The Minecraft API Is Now On Github

#16

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. On my machine that means it would end up being: /home/ajf/Projects/2012/Minecraft/Minecraft-API/src/main/java/net/minecraft/workbench/ Who on earth thought deeply nested directories for packages was a good idea?

Java has nothing to do with that. If you want to you can put everything in the default package (no nesting) or in a 1000 nested directory. Java does not stop you from doing this: Minecraft-API |- src

The project setup in the repository also has two "superfluous" levels of hierarchy:

       |- main
          |- java
At this early stage this seems like overengineering, and if at some point the project gets code e.g. javascript, it might be worth it to add ./js-src at the top-level first.

Re: The Minecraft API Is Now On Github

#17
post #14

Earlier quoted context omitted.

So it's a choice between bad and worse?

How else can it be done? If you want namespaces you can use them, if not you don't.

Well, obviously, by using them in the language without requiring them on the filesystem? I think you should be able to cat together all the .java files in your project and it should still compile. I guess you could easily do it using a very simple preprocessor.

Re: The Minecraft API Is Now On Github

#18
post #16

Earlier quoted context omitted.

Java has nothing to do with that. If you want to you can put everything in the default package (no nesting) or in a 1000 nested directory. Java does not stop you from doing this: Minecraft-API |- src

The project setup in the repository also has two "superfluous" levels of hierarchy: |- main |- java At this early stage this seems like overengineering, and if at some point the project gets code e.g. javascript, it might be worth it to add ./js-src at the top-level first.

Which has nothing to do with Java. The developer chose that hierarchy.

Correction: As per the message below I guess I should say that it has nothing to do with Java, the ecosystem, framework he is using is forcing him to use that hierarchy.

Re: The Minecraft API Is Now On Github

#19

The Minecraft API is going to make mod development SO much easier. No more decompiling and patching hacks. I've been waiting for this since Mojang snagged the Bukkit team. I look forward to the first client/server builds that support it. I added a Jenkins build job for it on BuildHive so anyone can download the bits if you want to play with the very limited banning API that they apparently have so far :) https://buil…

I managed to create a mod where you mostly use plain text Clojure files: http://metaphysicaldeveloper.wordpress.com/2012/04/20/conjcr...

Nonetheless the API is good news.

Re: The Minecraft API Is Now On Github

#20
post #17

Earlier quoted context omitted.

How else can it be done? If you want namespaces you can use them, if not you don't.

Well, obviously, by using them in the language without requiring them on the filesystem? I think you should be able to cat together all the .java files in your project and it should still compile. I guess you could easily do it using a very simple preprocessor.

If you do that you will no longer be able to tell the overall structure of your project at a single glance without using an IDE like Eclipse. Adding and removing packages becomes harder without the IDE. What are the upsides? You've increased the complexity for no good reason.
Post reply on HN