On most filesystems, plugins are loaded in lexical order because that's how the filesystem gives the files to us. This is a problem because it can hide bugs with dependency resolution on specific platforms with this behaviour, while inexplicably breaking on other platforms where the load order is different or undefined.
This change prevents plugins depending on any file yield order by randomizing the order in which plugin files are checked for loadability.
this doesn't come with a full impl because that requires some further changes like adding materials, which is out of the scope of this commit. This is here to prevent additional data loss in imported worlds.
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.
