Refactor commands #46
Conversation
|
The singleton thing should now be resolved. I guess naming schemes and the long methods are left to fix. Would it be worthwhile splitting commands of each category into their own (respective) classes? |
|
I think we should split all context & tab completion handlers into their own (enum) singleton classes tbh, would do a lot for readability |
|
Right, but say we split the commands into their own classes, should we register command contexts & completions by each command group, or everything in one place (or two, as per your suggestion)? |
|
I think we can keep the command methods in one class, but we should really be giving each context resolver its own class (because they're just interfaces) Although I wouldn't mind splitting command categories up either, like WorldEdit does it 🤷 |
|
Alright, I'll implement then mark dis as ready to review. |
This PR basically overhauls the original HyperCommandManager and splits the code into two classes - HyperCommand and HyperCommandUtil. The naming schemes are not exactly ideal. The HyperCommandUtil is essentially a singleton and deals with registering contexts, completions and locale messages. I am aware it does not look like a proper singleton at this point and this should be fixed before merging.