#182: Refactor command handling for maintainability

[kakdeykaushik]

#182

Dice cmds via struct

Summary of change:
Designed a struct to implement dice commands

Implementation details:
DiceCmdMeta encapsulates information about a dice command. A map map[string]DiceCmdMeta{} stores all the DiceCmdMeta objects and acts as a source of truth for all the commands.

• Eval method contains business logic of the command.
• if a command is not a valid DiceDB command then an error message is returned, earlier an invalid cmd was resolved as PING. This change is taken from Redis (refer img below)
• few commands which requires Client struct are handled separately in func executeCommand as it was earlier. Handling them gracefully is a topic of discussion.
• Info and Docs are kept placeholder and will be accomplished in Add support for COMMAND INFO command #148 and Add support for COMMAND DOCS command #146 respectively.

Redis reference:

Note - changes in core/eval.go be better viewed in spit mode

[yashs360]

Looking good, some minor changes requested.

[kakdeykaushik]

@yashs360 implemented the changes you had mentioned. please review and lmk of any improvements. Tests(both unit and integration) are working correctly with the changes.

[gauravsarma1992]

@kakdeykaushik @yashs360 The Eval attribute of the DiceCmd struct should be an interface instead of a function type. I think the current attributes of the function type are not sufficient to satisfy all future use cases. Using interfaces as the function's input and output would help provide extensibility for future changes as well. One basic distinction I see in the current system is that some commands require only the args whereas some commands require the args along with the connection information. This will also allow us to define commands in different packages as well as long as the objects satisfy the interface requirements.

[JyotinderSingh]

@kakdeykaushik @yashs360 The Eval attribute of the DiceCmd struct should be an interface instead of a function type. I think the current attributes of the function type are not sufficient to satisfy all future use cases. Using interfaces as the function's input and output would help provide extensibility for future changes as well. One basic distinction I see in the current system is that some commands require only the args whereas some commands require the args along with the connection information. This will also allow us to define commands in different packages as well as long as the objects satisfy the interface requirements.

Thanks for the inputs and suggestions, Gaurav. Maybe we can do that as a separate effort when it starts to become a problem instead of prematurely making it generic.

[JyotinderSingh]

Thanks for the contribution @kakdeykaushik, and for the review @yashs360.

Merging this.