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.
Warning for plugin developers: This is a silent BC break. It won't raise any errors.
This alters the default behaviour of event handlers to **not** receive cancelled events by default.
It is now required to opt into receiving cancelled events by using the @handleCancelled directive (or the handleCancelled parameter where it's appropriate).
The ambiguous @ignoreCancelled directive is now ignored.
Ramifications:
- The majority of handlers with `if($event->isCancelled()) return;` no longer need such checks.
- Handlers with `@ignoreCancelled true` or `@ignoreCancelled` annotations can have them removed.
- Handlers which want to receive cancelled events need to use `@handleCancelled`.
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.
given that inventory listeners are no longer allowed to fiddle with the outcome of changing contents, it's now possible to allow having multiple listeners receiving events.
It's likely that this will be used for network inventory sync in the near future.
there is nothing that these events do that can't be fulfilled by transactions. They complicate the internal implementation and produce unexpected behaviour for plugins when cancelled.
TL;DR: Use transactions. That's what they are there for.
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.
