Add Position

[Machine-Maker]

Position should be the eventual long-term replacement for lots of Location stuff. But for the moment, it shouldn't hurt to add it and start using it in new API where appropriate.

Feedback very encouraged as this interface will be used quite a bit.

Am not 💯 on the "aboveBlock, belowBlock, above, below" methods. I pretty much just took them from nms' BlockPos class, but Position isn't exactly the same since it has to account for more than just int block positions.

An alternative is to literally just have a BlockPos. I'm not sure if there are use cases for double coordinates separate from the world. Like NMS doesn't have that as a type anyways

[kezz]

I think both the fine/block position interfaces should override a lot more methods (like both the isBlock/is fine methods and the various toX methods) just to avoid unnecessary instanceofs and new object creation?

[Machine-Maker]

@kezz ok, I moved the isFine, isBlock methods, and the toBlock impl. but I don't see any other methods that would benefit from that? could you clarify (if there are indeed more of them)

[Machine-Maker]

Rebased for 1.19.3 and added javadocs explaining the Experimental annotation

[jaylawl]

Is it going to be immutable?! 😍

[olijeffers0n]

It is

[imDaniX]

Is it going to be immutable?! heart_eyes

Well, it's still up to implementation. While new default implementations are indeed immutable, Location now implements Position too, so x() and other getters may return different results each call.

[jaylawl]

Is it going to be immutable?! heart_eyes

Well, it's still up to implementation. While new default implementations are indeed immutable, Location now implements Position too, so x() and other getters may return different results each call.

In any case this is a step in the right direction. Despite being aware of mutability of locations, vectors, and bounding boxes, "accidental mutation" that was hard to find in the code, just keeps on happening. I've always wished all those classes were immutable.