Refactor: move function to new namespace

[hlship]

I would love an easy way to move a function to a new namespace, and update all callers within the current project. I've been doing this manually and it can be quite tedious!

Ideally, it would identify which other functions need to be carried along as well to make the function compile in its new home, and perhaps update the (ns) of the new namespace with any additional requires or imports.

Tricky, tricky stuff to be sure!

[cursive-ide]

Yes, this is definitely on the list. It's tricky, no doubt, and there are lots of details to get right. But this is one refactoring I'd really love to have, for whatever reason I do this a lot myself.

[jitlogic]

+1

[awkay]

This is the number one feature that I miss from Java/Scala devel. I refactor aggressively, and stuff moves around a lot. Very tedious to do by hand.

[danielcompton]

Dupe of #90.

[rutchkiwi]

+1

[jzwolak]

danielcompton, I do not believe this is a dupe of #90. If you look at the dependency tree of the namespaces in a project and say you're at the root of that tree and want to extract a function in the root namespace to a dependency of the root then the updates in the source code only have to happen to the current namespace. If however, the function is in a dependency of the root and you wish to make a lateral move to another dependency then updates to calls must be made throughout the entire project.

So it depends on how the solution to #90 was implemented as to whether this issue is a duplicate. But logically, #90 is a subset of this issue and this issue is more general.

+1 to this issue.

[CmdrDats]

almost a year old - will this get any attention soon? am always missing this feature when I'm in refactoring mode.

[crisptrutski]

+1 🙏

[LusciousPear]

+1 <3

[agrison]

+1 🙏

[mohsseha]

+1 🙏🙏🙏🙏🙏🙏🙏

[wbendick]

Is there any progress on this?

[hairybreeches]

How's this coming along?

[vvvvalvalval]

+1

[vemv]

I'd like to contribute the idea/observation that this isn't a IDE-specific functionality. Even if this was implemented in Cursive:

• other IDE users would not benefit from it
• from a technical POV, I doubt the accuracy of the refactoring would be safe enough, because of the approach Cursive takes to codebase parsing etc

Solutions like https://github.com/clojure-emacs/refactor-nrepl, https://github.com/xsc/rewrite-clj, the clj-kondo line of solutions, etc are a Thing™. Often they offer a public API, and don't require a tremendously different skillset than that associated to vanilla Clojure development.

So, quite feasibly, one could author a vanilla Clojure program with the following API:

(move! #'origin.ns/foo 'destination.ns/bar)

Such a program could be invoked from the repl, or from a task runner for extra cleanliness (refactor-nrepl owes its accuracy to the fact that it evals things).

I've been wanting to author myself such a helper but honestly I lack the time and am engaged in enough clj side-projects already.

If anyone around would like to give it a shot, you might have luck proposing it in https://github.com/clj-commons/meta or such, maybe with an accompanying POC. I could offer a bit of help (as I've hacked quite a lot with refactor-nrepl et al) if appreciated.