Implement session system for improved command and event api

[ColinHDev]

Currently, it is a big pain to send messages to players due to the complicated language system.

The idea is to introduce a Session class for each online player that handles all the weird logic for sendMessage(), sendTitle(), etc.
This should improve the API and remove a bunch of lines of boilerplate code.

The problem is the following:
Not all (sub)commands are sent by players, some like /p generate can also be run by the console. There are some ideas that came to my mind over the last few days:

• Session instances could also exist for the console, etc.
  • Pro: Sending the console messages is the same as sending them to a player.
  • Con: Since I also planned to include player-related attributes to it like PlayerData, another level of differentiation between PlayerSessions and others would be needed. Therefore the Session name also would probably not suit any longer.
• The Session class could implement the CommandSender interface.
  • Con: This is even less intentional than the idea above. Normally developers building plugins know that they can use $sender instanceof Player to verify that a command is run by a player. Now they would have to do that with another class, although the method in the subcommand class would look the same as any other in a normal command class.
• The command methods could stay the same and developers would have to call SessionManager::get($sender).
  • Pro: This is probably the least intrusive way.
  • Con: I don't think it's the best API design: It would be more friendly if developers could just use that class directly instead of having to get it from somewhere else.

Input towards this is highly encouraged, so that I don't end up implementing an inferior API design just because of missing input. 👀
Any opinion is welcome! ^^

[ColinHDev]

While writing this, I came up with the following as an extension of the first idea:

• CommandExecutor class: A class that represents any command sender (console, player, etc.) and has all required methods for that use case, e.g. sendMessage() but not sendTitle().
• (Player)Session class extending from the CommandExecutor class, which contains all player-related properties and methods like sendTitle().

[ColinHDev]

@supercrafter333, since you are the only person I know of, who worked with custom subcommand classes, I would especially be interested in your opinion.

[supercrafter333]

I think the first idea (and your Extension for it) is the best. Your second idea would be bad in production and your last idea would be a bit annoying for developers.

[ColinHDev]

Alright, thank you!