You might look at custom hierarchies for multimethods, but those don't get used a ton

It is easy to forget that multimethods dispatch isn't actually strict equality, but actually uses isa? which is like equality plus if you have a multimethod defined for java.lang.CharSequence it will be used if the multimethod dispatch function returns java.lang.String

I thought about that, but I'm hoping for "open ended" predicates. I'm hoping for a cond I can extend as I wish. The closest I've come up with is:

(def impls (atom []))
(defn register-impl [pred func]
  (swap! impls conj [pred func]))
(register-impl
  (fn [e _a] (fn? e))
  (fn [e a] (e a)))
(defn impl-chooser [e a]
  (reduce
    (fn [_ [pred func]]
      (when (pred e a)
        (reduced func)))
    nil
    @impls))

(let [func (impl-chooser e a)]
  (if func
    (func e a)
    (= e a)))

Not built-in, but https://github.com/camsaul/methodical :around methods may get you there.

Perhaps I'm misunderstanding what you are asking, but could you use a multimethod that uses a multimethod to dispatch upon?

What’s the dispatch function of the inner multimethod? Lol “how deep did this go????”

https://github.com/johnmn3/dispacio

I use expand-region for emacs it explained very well https://emacsrocks.com/e09.html

and you could bind to double-mouse-1 like so:

(define-key clojure-mode-map [double-mouse-1] 'er/expand-region)

I would imagine most IDEs support expanding the selection to encompass the form under the cursor, although I’m not sure about using the mouse. Calva, for example: https://calva.io/paredit/#selecting Not to plug, but Tutkain (https://tutkain.flowthing.me) also does, and I would call it lightweight, it nothing else.

After some reading about schema evolution in general, I've come to understand (and be convinced) that it's a good idea to keep all your fields optional to get full compatibility. However, when specifically reading about Avro, no one seems to advise this, but instead suggest providing default values with the record fields. Now, I see how this, indeed, does lead to full compatibility as well, but Chad Herrington (from Clojure's Lancaster library) has convinced me making the field truly optional (that is, type is union of null and the data type), is still a better idea. (https://github.com/deercreeklabs/lancaster/issues/21#issuecomment-1220055871)

So, my question is: 1. Do people here agree with Chad's (imo compelling) case that optional fields are preferable even over required fields with default values? 2. What reason could one have to favor required fields with default values?

Our use of Avro might be a bit exotic, but we've been always changing them in the following manner: • add new field, nullable • make old field, nullable • make new field required, remove old field Making everything optional at all times defeats the point of using Avro in the first place imho, but it depends on how you use them

Well the idea behind making everything optional is that you separate the concerns of evolution and validation. Evolution will be fully compatible at all times, and validation will be left to the consumer, which is a reasonable choice I'd say since it is hard to guarantee that (for example) all consumers will really require a field, now and in the future. Also, sometimes a specific consumer will want to add a field and state it as required, but other consumer might never use it. So I guess I'm curious in what sense you'd say it beats the point of Avro to make everything optional at all times. (Trying to learn here 🙂)

Ah yeah, these are valid points if you're using Avro with Kafka, our use of Avro is limited to RabbitMQ and own home-grown RPC system - so it's all about validation

Got it. I did approach this with Kafka in mind, wasn't aware to make that explicit. Thanks for sharing. It's nice to see another use case with its own choices

My immediate guess is that it needs (shutdown-agents) at the end.

yep that was it, TIL thanks!

there is a library called spectre that looks a lot like some of this

there are also these things from the functional programming world (haskell, idris, etc) called lenses and optics which also do similar kinds of things, and there are libraries for those in clojure as well

I'm using spectre already I don't think its api is remotely comparable to this specific usecase.

Tho it might help in implementing the function

There's also Meander which I believe is similar? (never used either)

Meander's examples aren't making a lick of sense to me

this just looks like pattern matching?

This is a kinda neat concept - lmk if you need help implementing it

I haven't used spectre, but what you are describing really does look like a permutation of https://github.com/redplanetlabs/specter/wiki/List-of-Macros#multi-transform

the selection portion of it looks a lot like using EQL on maps

This is very straightforward in meander. Unfortunately, I don’t have time right now to provide sample but the folks in #meander are super friendly

The meander expression would look something like:

(match m
  {:foo ?foo
   :bar {:a ?a
         :b ?b
         :c [?c & ?rest]}}
  {:foo ?foo
   :bar {:a ?a :b ?b :c ?c}
   :bazz (app inc (app count ?rest))})

Having extract-ops as a map will not preserve the order of those operations. otherwise looks kind of like a reduce if I blur my eyes a little

While meander, spectre, reduce et al have the functionality they don't have the declarativeness. And order of ops doesn't matter for my use case.

Not picking nay sides here, but isn't meander more declarative?

it's more verbose if you don't need the entire map in context at once

I think it's also not as compos able because it's a macro? Which would mean you need to have it in a match.

Not sure I follow regarding needing the entire map in context

And yes, it's a macro, but iirc you can splice defined data at call site. The other side of the coin is it has a pretty good compiler

Everything in context being like ?a and ?b available when creating the result

https://github.com/vvvvalvalval/supdate