Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespace the ops #710

Open
bbatsov opened this issue Sep 14, 2021 · 3 comments
Open

Namespace the ops #710

bbatsov opened this issue Sep 14, 2021 · 3 comments

Comments

@bbatsov
Copy link
Member

bbatsov commented Sep 14, 2021

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.

@r0man
Copy link
Contributor

r0man commented Jun 13, 2023

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

@bbatsov
Copy link
Member Author

bbatsov commented Jun 13, 2023

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

@r0man
Copy link
Contributor

r0man commented Jun 13, 2023

Ok, I will prefix the responses as well then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants