Added ClosureCommand

[dktapps]

this is intended to replace PluginCommand and CommandExecutor, both of which are overengineered and unfit for purpose. Allowing a closure allows much greater flexibility.

We can't use this within the core yet, as plugins will expect PluginBase->getCommand() to return PluginCommand (with its associated setExecutor() and similar APIs). However, I think this is useful enough to add by itself.

Changes

API changes

• Added a new ClosureCommand class. The callback accepted is similar to (and compatible with) the signatures required by CommandExecutor in the past, allowing easy migration.

Behavioural changes

None. This class is not yet used in the core.

While I'd like to migrate directly to this, various plugins expect that PluginCommand will be returned by PluginBase->getCommand().

In addition, there are questions about identifying plugin commands if this is used. This is no different a problem than we already see with regular Command users, but perhaps worth mentioning anyway.

Backwards compatibility

No BC issues.

Follow-up

• Deprecate and remove PluginCommand and CommandExecutor
• Perhaps Do not auto-register PluginBase->onCommand() #5960 ?

Tests

Not directly tested, but this is trivially PHPStan-verifiable.

[dktapps]

I'm not sure whether we should allow replacing the closure handler a la CommandExecutor->setExecutor(). setExecutor() is used by some plugins to provide custom handlers for commands declared via pocketmine.yml. The command can just be re-registered with the new handler, so I'm not sure whether this is needed or not.

[SOF3]

Let's not overcomplicate the API. Mutable executor may as well be implemented within the closure as a delegation where it matters.

$this->cmd = new ClosureCommand(xxx);
$this->cmd->setClosure(xxx);
register($this->cmd);

is barely different from

$this->closure = xxx;
register(new ClosureCommand(fn(...$args) => ($this->closure)(...$args)));

[dktapps]

Delegate won't be available if the command was registered by the server from plugin.yml. That's basically the whole use case.