Refactor: Reorder parameters - 0.1.09

[hlship]

This seems like the easiest of the possible refactorings; I would simply like to re-order the parameters to a function (or macro) and have Cursive locate and update all the callers of the function.

The greatest challenge, and this probably applies to all Clojure refactorings, is providing warnings when the function is assigned to a local symbol (or other, similar higher-order behavior). For example:

(defn foo [a b] ...)

...

(let [f foo] (f gnip gnop))

If the order of parameters a and b are reversed, what can and should Cursive do on the later let expression?

I think a warning when the refactored function is used in any expression; in this trivial case you could imagine that Cursive could reverse gnip and gnop when a and b are reversed. However, something this simple doesn't occur in real code, whereas capturing the refactored function (including through the use of partial, etc.) does happen and a warning would be nice.

Perhaps Cursive could automatically add bookmarks at points where a refactored function is captured with text such as ("function a.namespace/foo was refactored; the order of its parameters was changed.").

[cursive-ide]

Interesting idea - you're right, it seems like some sort of search (perhaps a Find Usages option) would be useful to find all uses of a symbol which identifies a function, in a situation where it's not being used as a direct invocation. In terms of automatically identifying cases, that would require a full dataflow analysis which I suspect in Clojure would be impossible on non-expanded code (imagine storing a function in a map, for example).

I like the idea of marking previously-refactored symbols in the editor in these cases, but it might be tricky since you wouldn't want them marked forever, and it's impossible to tell when the code has been updated for a particular case. Or maybe you would want them marked forever, and these symbols could be subtly identified in the editor somehow and have a "Refactoring history" option to see all refactorings that have affected the function - I actually like that idea. I'm not sure how much metadata that might generate though, and maintaining the list throughout further refactorings (renaming symbols, extracting functions and inlining them, and so forth) would be tricky.

[jitlogic]

+1