Proposal to use code generators to implement clients.

[samhendley]

I have actually been thinking that manually keeping up with the commands may too difficult. Alot of this code could actually be generated given a good definition of the command set. Antirez maintains a commands.json file that describes all of the commands, we would need to update this to include the return type but then we could use code generation to build all of the command interfaces and implementations.

https://github.com/antirez/redis-doc/blob/master/commands.json

There is the downside that the code may lose a bit of "hackability" but it would eliminate a huge class of bugs in the library and make maintaining the different clients much simpler. When new commands are added in future versions of redis it should generally be as simple as updating the definitions file and rebuilding.

For example this commit implementing an "internally pooled" client shows how unwieldy creating a new client type is. I didn't notice any bugs but it would a very straightforward job to automate this class with code generation. https://github.com/brianchen2012/jedis/commit/0079d2b21ebe57cd3d4e0a1860b581641e39a68d

I have done similar things in the past and have found it to be very powerful. If we are doing code generation some of the requirements we have of "manually written" code can be relaxed. If we wanted a pipelined version we would need to copy+paste that whole class just altering return types etc.

I don't think this necessarily hurts the simplicity and hackability of the library. The code itself will still be readable and if someone wants to build a new client they can do so manually. In fact most development should start like that, manually implementing the first few versions then deriving the template. This would just mean there would be much less code we would need to manually write and maintain.

If there is interest in this proposal let me know and I can prototype a generator solution covering the current interfaces and clients.

[Akaame]

I still think adding new commands can be automated in this fashion, as commands.json is still actively maintained and most of the PRs and issues for the library have the format of "Add support for VERB arg modifier optional_arg" now a major release is coming up.

[github-actions[bot]]

This issue is marked stale. It will be closed in 30 days if it is not updated.