cider-nrepl icon indicating copy to clipboard operation
cider-nrepl copied to clipboard

Namespace the ops

Open bbatsov opened this issue 3 years ago • 3 comments

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 avatar Sep 14 '21 07:09 bbatsov

@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?

r0man avatar Jun 13 '23 07:06 r0man

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

bbatsov avatar Jun 13 '23 07:06 bbatsov

Ok, I will prefix the responses as well then.

r0man avatar Jun 13 '23 07:06 r0man