_clj_ -Spath should be in .m2 or .gitlibs

looks like .m2, not .gitlibs

it’s .m2, yes. I tried deleting the mkl path but still get the same error

you might try going one directory back to get any other lock files in the dir

~/.m2/repository/org/bytedeco/mkl or something

there is only a 2020.3-1.5.4 folder after running -spath again, no other file

I think maybe the issue is my intellij project that throws the error

-spath downloaded some more files and I can just run clj in the directory

ok seems to work now, not sure what the issue was

Sounds like https://clojure.org/guides/spec could help

That would be like a :pre condition on the function, except more concise, right?

Yes, but more purpose built, and well thought out. You also get some extras, like generative testing and instrumenting spec'ed functions only in certain (dev/test) environments.

for validating structure and simple types, i have found malli very quick and simple. the schemas in malli look pretty close to the data they are validating. however, could you go into more detail about how you are refactoring? i use clojure to transform arbitrarily nested trees, where i actually don't know what parts of the top nodes look like, but i do know a bit about what the middle nodes look like, and sometimes i don't even know what the leaf nodes look like. so maybe i can be some help with techniques i have found helpful

i don't typically use functions as field getters/setters, as once your tree has duplicate data in it (very common), these functions become context sensitive, and setting data requires changing things in multiple places. it's really common in clojure to process data, keep the old version somewhere close to the processed version (meta, or map key), and you quickly end up with a big mess. it's also common to duplicate data and change a field or two because the meaning is different (similar to making a view classes for different components of the same data)

for your points, i think i covered #1. #2 there are things about records that make them less convenient to use than maps, and these are a bit rare in clojure now. #3 is basically using asserts everywhere, this is common in debugging, but :pre and :post are pretty bad at telling you what is wrong, using a full blown schema like malli is 100x better because it'll pretty print the exact point where your data mismatches the schema. however i think schemas are more used at the boundary of apps. I think if you trust your code so little, you may be better off at writing some tests against it, as it's easier to convey meaning in those, than in asserts and function schemas

Hey @UJY23QLS1 & @U0LAJQLQ1, thank you very much for your responses! Regarding spec/malli: I am already using malli to validate at the boundaries, and it didn’t seem to be the right tool here. Regarding what I am refactoring: The part I am refactoring is about payroll calculation, for which a map is chained through a couple of functiions: At first the map is enriched with all parameters necessary for payroll (like premiums, employee age calculations, region specific clauses), afterwards the actual calculation takes place, using the the data from the map as input. Now I want to restructure this map and let’s say I don’t have much confidence in my find+replace skills 🙂 I have plenty of unit tests for each function, but the overall end-to-end test is missing yet - my takeaway from this discussion is that this is what I have to fix, instead of runtime checks.

ok, maybe something like https://github.com/plumatic/plumbing defnk can help you find functions with bad arguments mappings

i sometimes use these for that exact purpose, and after a while i convert them back to defns

the error reporting on defnk is very good, the overhead is low, and translation from defn is easy

Very interesting! Thanks a lot!

Btw. they using an assertion in their example, this is another option we haven’t discussed (though similar to spec/pre-condition)

assert is better than :pre for reporting errors, spec is better than assert, but takes more work. if you need type reporting spec is ok, i find it cumbersome compared to defnk but i don't typically care about types cus clojure will do ok reporting type errors.

I find myself doing (let [x 1 y 2] (foo {:x x :y y})) often enough..

https://github.com/worldsingles/commons/blob/master/src/ws/clojure/extensions.clj#L152

Good stuff. Glad I asked. Thank you, @UJY23QLS1.

another version we use: https://github.com/jaycfields/jry/blob/master/src/clojure/jry.clj#L97

For the example up above there are no vars

@U0NCTKEV8 what do you mean?

Local names like those bound by let don't get vars

Ah, I see. So my problem description has a bug, but both of the suggested snippets will work.

Is there a version that also works in cljs?

First, a question about why you have the fields to update in an atom in the first place?

If it's just to have it modified inside that function then: • just pass the hash map of fields • instead of when / swap!, do cond-> assoc

So your function becomes:

(defn generate-update-input-map [arguments fields-to-update]
  (let [target_lpi (:target_lpi_as_date_str arguments)]
    (cond-> fields-to-update
      target_lpi
      (assoc :target_lpi (format "'%s'" (format-local-date (str-to-date target_lpi)))))))

Then (generate-update-input-map args {:existing "fields" :to-be "updated"}) will return the fields with :target_lpi added if it needs to be there.

Got it, thanks Sean

If you find cond-> hard to read, you could do

(if-let [target_lpi (:target_lpi_as_date_str arguments)]
  (assoc fields-to-update :target_lpi (format "'%s'" (format-local-date (str-to-date target_lpi))))
  fields-to-update))

this is what I was looking for.....

thanks again