While I'm looking at stats • 1113x reg-event • 331 reg-sub

emacs does indeed have some impressive refactoring https://github.com/clojure-emacs/clj-refactor.el/wiki

I have some good news and some bad news. The good news is that Cursive’s moving things around refactorings will get better soon, due to some work I’m doing now on ns rewriting. The bad news is that: > roll your sleeves up and do it systematically. It won’t be fun. is still going to be the correct answer.

you could use something like doom emacs or spacemacs if you want an emacs distro that helps you get things all set up for this kind of thing

I’m interested to know what you mean by splitting out registrations, what is involved there?

@U02N27RK69K nice idea thanks

AFAIK Emacs’ refactorings don’t yet work on CLJS either, since they’re REPL based.

I might be wrong/out of touch there, though.

@U0567Q30W that one is pretty mechanical... I have lots of (reg-event-fx ::name (fn []...)))

I want defns for handlers

I might move the reg-event-fx to another file

So move an fn to a defn and replace the original with a reference to the new var?

I can almost do it neatly with many cursors but there's no way to make a nice defn name based on a fully qualified keyword

That's the idea

If I could kebabify the qualified keyword en-mass I'd be basically happy

Yeah, the name suggestion is a big part of that.

@U0567Q30W sepearate but a way to replace all "::" use across the codebase would make moving stuff between namespaces safer but perhaps your new developments will cover that.

All surmountable really

Yes, copying and pasting between namespaces will get better shortly, I’ll be fully-qualifying all code before copying it, and then shortening the qualified version on paste, which is what IntelliJ does for e.g. Java.

sounds perfect

I didn't think about the fact it was cljs @U0567Q30W, good call

I question "easier to reason about and maintain"

clojure-lsp has some refactorings that may be helpful

https://clojure-lsp.io/features/#clojure-lsp-extra-commands

For any sufficiently complex system there are many cross cutting concerns for everything, so any single organization is going to obscure things

So there is no promised land, and if there is no promised land, is there really a benefit to doing a code base reorg?

And what are the costs? How many man hours, rewriting, testing, for no additional features

Let's not embrace chaos just yet!

It was a bit of a throwaway statement. There are various justifications for specific refactoring in this case.

Let's save the subject for another thread.

(At me into it if you feel like exploring)

Before doing big refactoring you might want to use something like CodeScene: http://codescene.com

Interesting.

Have you used that with Clojurescript before?

Not really but we use it for Clojure backends (I'm obviously biased since I work for them :) )

@U055DUUFS what specifically isn't easy to reason about or maintain?

I see kebabify namespace keys as one thing, that’s just a regexp away. @U055DUUFS what exactly would you like to do?

There's been a enough random pokes on the specific challenges i'd like to improve on in this specific codebase. I'll work up a gist and share them. Regarding kebabify. There are over 1000 event handlers registered across the codebase, say 50 files. We often used the (reg-event-fx ::x (fn [a b]...)) pattern. I want defns for each handler for testing purposes. I also plan to move registrations out of the namespace so tests can load files without having registration side effects. The event id was either ::foo or :bar/baz and sometimes either/with.dotted-name. Using IntelliJ I can use the multi-cursor approach to find reg-event, copy the keyword, find the fn, make it a defn above the registration. The niggle is picking a sensible handler name. It often works to take the event-id (keyword) and use the name with a "-handler" suffix. Not always though. A dot in the name part leads to an invalid symbol. Two events with the same name part causes a clash. Handling the three forms of keyword makes the process fiddly.

And time. Place-time 😄

in fact, in The Value of Values, where https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ValueOfValues.md was coined, Rich Hickey makes a very similar distinction between place and space: > What's really interesting about the definition of space is that it has always, if you go back to the oldest definitions in the oldest languages, the definition of space has always incorporated both place and time. It's never been something that applied only to one or the other of those two things. It's always connected to two and there's a certain physics aspect to that. One thing I like about that Conal Elliott paper is that it gets away a bit from the assumption of "infinite space" that's in Rich Hickey's argument, while still keeping the notion of space appropriately abstract. I think the assumption of unbounded and forever increasing computational resources (a common assumption across our profession, definitely not limited to this talk - and he does talk a bit about needing to manage garbage and reclaim some of those storage resources) is one that is ultimately quite unsustainable from an ecological point of view.

Neat, I appreciate your chiming in on the distinction between space & place