cider-nrepl
cider-nrepl copied to clipboard
Namespace the ops
Right now cider-nrepl
doesn't namespace its ops, which in the past became problematic when we decided to add a completion op to nREPL. Normally it would have been named complete
, but we had to go with a different name, as cider-nrepl
already had complete
.
It'd be nice to give all the ops names like cider/info
, cider/complete
, etc. This has to happen in several steps, though:
- first we need to add the new names alongside the old names
- update the docs to promote the newer ops (and maybe send some notifications to clients when using the legacy names)
- give the clients a few years to update
- drop the old "global" names (optional step)
In general new ops shouldn't use the global namespace. The same applies to refactor-nrepl
.
@bbatsov I'm going to do this for the log middleware. Does this also apply to the response keys? Looking around the middlewares I see that many of them return the responses under the same key as the op name. As a concrete example, I have the op log-frameworks
which returns the list of log frameworks under the key log-frameworks
. Now that I rename it to cider/log-frameworks
should the response also go under cider/log-frameworks
key? I believe the automatic error responses from with-safe-transport
does return something like cider/log-frameworks-error
. Wdyt?
Yeah, I think that makes sense, as we can have a collision in the name of responses as well. As requests and responses are normally matched on their IDs that's not a big problem for most clients, but the IDs are optional so who knows what someone might be using.
I definitely regret not thinking more about the proper namespacing of ops earlier in the dev process. :D
Ok, I will prefix the responses as well then.