this was an old hack to prevent debug spam being emitted when we halted decoding of logins over breaking protocol changes. Since then, we've gone back to trying to decode the packet regardless, so this property is useless.
There are a few motivations here:
1) Less boilerplate code (this can be written inline)
2) It's possible to provide multiple constructors for different packet variations to reduce the chance of errors.
3) It makes things catch fire on updates in ways that static analysers can understand.
Non-closure callables have strange context-dependent behaviour and are slower to call than a closure. It's possible to use Closure::fromCallable() in the origin scope, which guarantees that the callable will remain callable no matter where it's used.
It's not guaranteed that objects provided are the same as those in the enum registry, so they can't be directly compared.
Implementing comparison with === would require some kind of __equals() implementation or an extension to hook into such functionality.
the "simple" name comes from the early days of this refactor before I started splitting everything up into their own units. This handler is now in good enough condition to have a proper name.
this causes bugs when a packet is modified during events and then re-sent to a player. Since we can't control this, we can't allow this kind of buffer reuse.
The only notable case where this will cause loss of performance is when broadcasting a series of packet(s) which accumulate to less than 256 bytes, which is reasonably cheap to encode anyway.
In addition, removing this caching is one roadblock to moving this serialization to native code, which will make it vastly faster.
it's better to encapsulate all this logic in one place so that third party developers can more easily understand this, and also to reduce the amount of crap we have in Player.
This has been a pain point for a long time due to the misleading nature of the name "level". It's also confusing when trying to do things like getting the XP level of the player or such, and also does not translate well to other languages.
This transition was already executed on the UI some time ago (language strings) and now it's time for the same change to occur on the API.
This will burn a lot of plugins, but they'll acclimatize. Despite the scary size of this PR, there isn't actually so many changes to make. Most of this came from renaming `Position->getLevel()` to `Position->getWorld()`, or cosmetic changes like changing variable names or doc comments.
