Spennende grep.

Nei, det vil jeg ikke påstå. Dette er jo bare imperative shell, functional-core applisert til tid.

Veldig fornuftig. Og kan utvides til å inkludere alle funksjoner som defaulter noe som helst som har med tid å gjøre - feks tidssone.

Spennende for meg 🙂 Gir liksom en kombinasjon av pragmatikk, “det er bare data”, immutability og isolasjon av sideeffekter. Jeg ville ikke kommet på å gjøre det sånn. Hvis det er modus operandi / åpenbart / trivielt for dere, er jo det flott for dere!

Det er vel såvidt lite åpenbart/trivielt for meg at jeg finner det verdt å dele her. Også fordi jeg merker at jeg er litt stolt over å ha innført dette arkitektoniske grepet

En annen mulighet er å sette en instans av java.time.Clock på :ctx , f.eks Clock/fixed. Mange java.time-metoder tar Clock som argument. Da kan du lage testbare funksjoner som håndterer tid, men som likevel er pure.

Nice!

Clock har jeg ikke brukt. Er det en slags konglomerasjon av instant og tidssone?

"A clock providing access to the current instant, date and time using a time-zone." https://docs.oracle.com/javase/8/docs/api/java/time/Clock.html Har bare brukt en eksplisitt Clock i forbindelse med testing (`Clock/fixed`), men hele java.time bruker en implisitt systemklokke som baserer seg på hardware + JVM-konfigurasjon for tidssone - hvis du ikke overstyrer ved å sende med en klokke. Se f.eks. Instant now() og Instant now(Clock clock) : https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#now--

Interessant. Jeg har løst dette litt tungvindt ved å være eksplisitt på now og tidssone.

Eksempel på bruk i test: https://github.com/msolli/proletarian/blob/d34aa863f89dfcdf563a7690fcdb8f971ea26d02/test/proletarian/retry_test.clj

Funksjonen som testes, retry-data, gjør tidsaritmetikk, men er likevel pure siden den får inn Clock utenfra.

Jeg tror til vårt forsvar at vår bruk av clj-time er fra før java.time var en greie (man brukte vel Joda time på den tiden). Og jeg har ikke helt sett verdien av å bytte det ut, det største problemet er jo folk som insisterer på å spørre om tiden både her og der, og det ungår du jo ikke med java.time heller.

Nei, ser den

Og ser det historiske aspektet

Såvidt jeg kan erindre så har clj-time langt flere footguns i form av funksjoner som defaulter ting som burde være eksplisitt. Men sikkert ikke grunn god nok til en stor og risikabel endring.