This PR started out as an effort to decouple Command and CommandMap, but it's turned into a bit more than that.
A summary of changes:
## UX
- Added `cmdalias create`, `cmdalias delete` and `cmdalias list` commands
- `/help` now shows prefixed names such as `pocketmine:help`
- Prefixed command name (e.g. `pocketmine:help`) are now visible to Minecraft clients
- Permission denied messages are now able to show more useful context when e.g. checking subcommand permissions
- Multiple commands claiming an alias make the alias unusable (an error will be shown when used telling the user to pick from the namespaced names), instead of whichever plugin loaded last getting lucky
## API
- Added `CommandAliasMap`, which handles mapping of aliases to namespaced command IDs
- Added `CommandSender->getCommandAliasMap()` for user-specific aliases
- Added `CommandMap->getAliasMap()` for global fallback aliases
- `Command` no longer tracks its own registered aliases (now the job of `CommandMap`), breaking circular dependency
- Aliases must now be provided to `CommandMap->register()`
- Aliases can now be individually registered and unregistered without re-registering/unregistering the whole command using `CommandAliasMap` APIs
- Aliases are no longer namespaced, only the main command name (e.g. `pocketmine:?` is now gone while `pocketmine:help` still exists)
- `Command` now requires a `$namespace` parameter, which replaces the old `$fallbackPrefix` parameter of `register()`. It should be set to the name of the plugin.
Relevant issues
- #6508
- #3371 - this PR doesn't implement storage, but allows configuration of per-user aliases during server runtime
it doesn't make sense to have to parse the string every time we want to verify permissions, nor to expect that people will somehow know to use ; to separate them without it being documented anywhere...
getName() essentially serves as an ID for the command for CommandExecutors. It has no other sane use case.
Since it's not unique (multiple commands with the same name may be registered, and the fallback alias will be used on conflict), it cannot be used for array indexing. It's also not correct to use it for any display purpose, since the command may not be able to be invoked by its 'name' if there was a conflict.
There is an open debate about what to do with getName() and the wider CommandExecutor ecosystem, but that's a topic for another discussion.
closes#5344
this avoids duplicate timings entries when command labels are changed and changed back, or if multiple command maps are in use.
In addition, it also solves some PHPStan issues :)
this resolves many security issues, as well as removing a ton of boilerplate code.
It may be desirable to react to permission denied; this can be done by overriding Command->testPermission(), or by using setPermissionMessage() to set a custom permission denied message.
the use case for this is basically zero, since the community prefers implementing their own subcommand systems instead (which are much more flexible).
In addition, allowing spaces in command names makes it extra complicated to display helpful information to the user, such as the command that was actually accepted by the command map (which would be useful for identifying accidental invisible characters / control characters when sending commands).
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
