phpstan doesn't report these because .. reasons .. @ondrejmirtes this is causing bugs to go unfound :(
I'm aware of the irony that I just silenced the bugs that were exposed by this commit .. that's an architectural problem for another day
previously, these were forced to extend BaseInventory because of the amount of crap in Inventory's interface.
This meant that these inventories had their own slots storage, which would be _mostly_ unused because these inventories aren't real inventories, but rather just delegates.
This lead to a variety of bugs in the past, such as certain API methods on BaseInventory not working correctly for DoubleChestInventory in particular.
Now, BaseInventory just implements the functional part of the inventory implementation, leaving the storage system up to the implementation.
A SimpleInventory class is provided with a simple SplFixedArray storage backing, which is used by most inventories.
EnderChestInventory and DoubleChestInventory now extend BaseInventory directly, and implement custom methods for dealing with their delegates.
now, EnderChestInventory is just a temporary window, much like anvil/enchanting windows. It provides a gateway to the player's PlayerEnderInventory.
This removes one of the remaining obstacles to disallowing null World in Position constructor.
* Allow plugins to use PSR-4 namespace mapping
this is a reduced implementation which serves the 99% use case without being horribly breakable.
Plugins may now specify a `src-namespace-prefix`, which should be set to the namespace of the classes in `src`.
If the old system is used, `src-namespace-prefix` can be omitted, or set to an empty string.
Examples:
- If `src-namespace-prefix` is `dktapps\test`, `dktapps\test\Main` will be searched for in `src/Main.php`, instead of `src/dktapps/test/Main.php`.
* Migrate TesterPlugin to PSR-4
this implementation is very rough due to having to hack around lots more MCPE bullshit, and currently doesn't allow dynamic coral types; but it's there. We'll clean this up after 1.13 migration is done.
since a while ago, we're anyway just discarding the internal buffer anyway when the packet is repeatedly encoded, so this doesn't serve any advantage anymore.
We do need a system to be able to reuse encoded packet buffers, but right now we're not reusing them anyway.