like-some? about plumbing

[w01fe]

Thanks for your interest in contributing.

We're pretty mindful of keeping plumbing.core small -- just to those things we wish were in clojure.core, more or less. That's a pretty high bar; internally, we have a plumbing.core-incubator namespace, and only things that marinade in there for a few months and see a lot of usage are considered for inclusion.

Are there any of these that you find particularly useful and think meet this standard? FWIW, update is already in there.

[ccfontes]

That's cool. Then I'm going to use the incubator namespace if it can reduce my codebase. Btw, can you provide me a link to that namespace? (it's embarrassing but I can't find it haha)
The ones I would really like to see in clojure.core:

• defcopy - useful for aliasing a form while keeping its metadata. I use it to keep the docstring for aliases.
• ffilter or find-first - this one doesn't need introduction.
• update-each - useful for updating several map keys with same fn.
• update-multi - useful for updating several map keys with several fns.
• or-> - too often do I find myself using the original value when -> returns nil (but can be used for false too).
• unlazy - this one is just so useful, when you want to revert from the lazy-seq to the input type when doing map/reduce/filter.
• map-dregs would be cool too for clojure.core, but I'm not sure how frequently it would be used.

update-multi and unlazy are names I came up with. They could be named differently.

[ccfontes]

Well defcopy wont work in cljs and current impl of or-> also.

[w01fe]

Cool, thanks. core-incubator is an internal thing currently -- it's by definition unstable, so not sure it's something we actually want to expose publicly.

defcopy: we're currently using potemkin/import-vars for this.

find-first: a deliberate omission -- we decided it was not shorter/clearer enough to merit inclusion.

update-each: how often do you want this rather than map-keys?

update-multi: could see this as useful, but I'm not sure how often. If anywhere, it would probably go in plumbing.map -- will have to think about it.

or->: when do you find yourself using this? I don't think I've really seen this pattern (and using eval like this is a big no-no IMO).

unlazy: I think mapv fills most of this niche for us, and I think being explicit is often a good thing. I think this also reverses the order for lists?

[ccfontes]

potemkin/import-vars looks neat. defcopy allows me to additionally rename vars, which import-vars doesn't (it seems). I do rename them a lot btw :) I even make copies of the var in the same ns, for different naming tastes.

I use map-keys and update-each. The former updates all keys with one fn, the latter updates values of selected keys with one fn, so they are quite different. Maybe the naming is ambiguous. An example: (update-each {:a 1 :b 2 :c 4} [:a :b] inc) => {:a 2, :c 4, :b 3}

update-multi: I use it 2 times here and it's just 128 LOC. It may be some design fault on my part, though haha.

or->: I'm only using it in the same source file, even though I felt the need for it in the past many times. The example is too simple, though. I think of it as defaulting to the original value when the result is false. Maybe the name is not the best either. I found some issues with the fn (besides eval of course) so better ignore it for the moment. Sorry about this one. It's not mature enough.

unlazy: yes, it reverses lists, well spotted! I guess I never tried it with lists haha. Being explicit is sound. Which fn do you use for maps?

So it leaves us with defcopy, update-each and update-multi. Do you want to leave defcopy out also?

[w01fe]

Thanks for the details. I think we'll skip worrying about defcopy for now, until we do something with potemkin. For update-multi, after looking at these examples, I think just a -> with multiple calls to update is clearer, and nearly as short. Do you have concrete examples of where you use update-each?

Sorry for being a stickler about this stuff -- but I've spent way too much time over the years cleaning up huge namespaces of my utility functions that seemed like a good idea at the time but in hindsight weren't really net wins.

[ccfontes]

Yes, one could do that with ->. My point there was to save 1 line. Maybe it's not as readable if each key must go in a different line anyway, but if it's a small one liner, I think it's a win, like this one in that file: (update-multi {:allFeaturesArray seq :partOfSpeech #(split % #",")}). I would argue that if it's a 1 liner, readability may increase, when comparing to :keys scattered through lines + ->.

I found just one example of update-each in my codebases:

(defn sync-timecodes [unsynced-sub synced-sub]
  (let [time-offset (- (-> synced-sub :events first :Start)
                       (-> unsynced-sub :events first :Start))]
    (update-in unsynced-sub [:events]
      (partial map
        #(update-each % [:Start :End] + time-offset)))))

Both :Start and :End would naturally be updated with the same fn when shifting time by an offset.

Don't worry, I'm already learning a lot with this ping pong and it was a pleasure :)

[ccfontes]

It's clear by now there isn't an obvious need of any of the remaining forms, so I'm closing this.

For future reference, you may want to see defcopy, update-each and update-multi.

Thanks for the discussion. It was really useful for me.

[w01fe]

Thanks for understanding -- we'll keep these in mind for future updates.