Skip to content

KWCommands vs WCommands

Jump to bottom
Jonathan edited this page Dec 26, 2017 · 5 revisions

KWCommands vs WCommands

This page is intended to give information to help migration from WCommands to KWCommands, this page will not explain how to do that, only give information about important changes.

KWCommands is a full rewrite of WCommands in Kotlin with a bunch of improvements.

Command API

KWCommands does not require a RegistrationTicket, KWCommands uses a Object instance as key of commands (called owner).

Sub Commands

In KWCommands, Commands are not copied to a new instance when registered, modifications in commands will be reflected in all registered commands, this does not happens in WCommands.

Handling

Same behavior as WCommands, the main difference is that KWCommands supports argument handling.

Interception

Same behavior as WCommands, the main difference is that KWCommands supports argument handling interception.

Reflection API

The Reflection API was improved:

  • Fields are ALWAYS arguments of class commands. Why? Because you never invoke a field. You either set a field or access a field, you never invoke a field.
    • To exclude fields use @Exclude annotation.
  • Short annotation names: Arg, Cmd, Info, Require.
  • Reflection processor is a helper class (in WCommands it is a command manager).
  • Common Command Processor is less subject to bugs (First version is more stable than WCommands version) (I've to fix a lot of bugs of WCommands parser and processor, and probably a lot still exists).
  • No more 'Command Error Handling Helper'. Handle errors yourself. The WCommands error handler is very bugged, sometimes fails to handle errors, throw same exception two times and is useless. If a error occurs during command parsing or processing, entirely process will be stopped (this does not happens in WCommands, and is in mostly cases a bad behavior).
  • Custom argument parser does not require a bunch of classes to be created to achieve the translation.

Requirement and Information

Information API is almost the same as of WCommands.

For Information API, the change was the name of class that manages information, from InformationRegister (WCommands) to InformationProviders (KWCommands).

For Requirement API, the change was bigger, now we have a Requirement, that specifies the subject information id (Information.Id), required value and a RequirementTester that determines if the subject matches the requirement. Read more here.

Command Manager and Command Processor

In KWCommands, the command registration is separated from the command processing, CommandManager manages the commands and CommandProcessor process the commands, the processing steps is the same of WCommands, first you need to process the command string list, and then handle the command list returned by process.

Because of the Requirement change, in KWCommands you don't need to register requirements like in WCommands (using Requirements class)

Extensibility.

In WCommands you are free to extend Reflection API without needing to rewrite the implementation, but this was the main reason to rewrite the project, the extensibility limited the evolution of command system. In KWCommands there is no way to extend Reflection API, but we plan to provide a basic way to do that.

Clone this wiki locally