clojure-norway

hypirion 2025-12-17T06:46:36.831589Z

Morn!

slipset 2025-12-17T06:49:58.275999Z

Mrn

eaj 2025-12-17T06:51:03.778759Z

Morgen!

cjohansen 2025-12-17T06:55:37.829309Z

Morn!

mokr 2025-12-17T07:07:55.865989Z

Morn!

msolli 2025-12-17T08:06:10.898329Z

Morn!

emil0r 2025-12-17T08:18:02.100159Z

Morn

2025-12-17T08:18:40.146309Z

god morgen!

teodorlu 2025-12-17T09:16:32.531619Z

god morgen!

gunnar 2025-12-17T10:26:19.563359Z

Morn!

2025-12-17T12:08:03.796259Z

hvordan jeg har klart meg i snart 2 år på Kotlin-prosjekt uten denne er et godt spørsmål. Savner Clojure stdlib 🥹

fun <K> Map<K, Any?>.updatef(key: K, block: (value: Any?) -> Any?): Map<K,Any?> {
    return this + mapOf(key to block(this[key]))
}

msolli 2025-12-18T12:32:34.178569Z

Om ikke annet så vaksineres vi fint mot eventuell trang til å bytte programmeringsspråk. 😄

😂 1
gunnar 2025-12-17T12:27:28.668449Z

Standard-biblioteket for immutable collections er egentlig overraskende mangelfult. Dette er en gjenganger hos oss:

obj.copy(
    foo = obj.foo.copy(
        bar = obj.foo.bar.copy(
            baz = object.foo.bar.baz.copy(
                 :sob:
            )
        )
    )
)

2025-12-17T12:28:15.916039Z

dataklasser er jo ganske snåle egentlig, ikke noe interface eller noe sånt, bare en duck typa overflate med noen funksjoner som ikke kan brukes på noe generisk collection-vis

2025-12-17T12:28:23.929539Z

Rich Hickey skriker at maps må være maps

gunnar 2025-12-17T12:29:17.212729Z

jepp, men mangelen på keywords gjør at maps ikke er en god løsning i java/kotlin. Det blir en PITA

teodorlu 2025-12-17T13:24:20.334309Z

Jeg har prøvd meg bittelitt med å ha en svær enum med alle attributtene. Da får man en form på typesikkerhet og completion, og slipper å bruke strings. Men jeg har aldri tatt sånn kode i produksjon!

gunnar 2025-12-17T13:27:13.004359Z

Det er kanskje en løsning. Manglende namespacing kommer sikkert til å savnes, dog.

2025-12-17T13:31:36.823659Z

dette skriker kanskje "Clojure i Kotlin", men vi har en del typer som dette:

Map<KProperty1<B2BCustomerEntityData, Any?>, Any?>

2025-12-17T13:32:03.386829Z

da kan vi lage maps hvor nøklene er kjent type i dataklasse, f.eks:

mapOf(B2BCustomerEntityData::countryIsoCode to "NOK")

2025-12-17T13:32:18.792789Z

verdien blir naturligvis ikke typesikker, men vi bruker det til å ha litt mere enn null typesikkerhet på "partials" av dataklasser

gunnar 2025-12-17T13:44:31.771349Z

Kult! Hvordan er det med serialisering av KProperty1? Går det greit?

2025-12-17T13:49:14.528379Z

vi bruker det ikke direkte til serialisering, vi får det inn som JSON og så er det litt jackson hit og dit og herjing før det blir gjort om til det mappet der. Så i API-flyten har det ikke så mye og si i praksis. Men i ny og ne skriver vi "manuell" kode som ikke får map-et som user input, og da er det jo kjekt med litt hjelp fra typesystemet

2025-12-17T13:49:39.673609Z

i tillegg har property-instansene annotasjoner på seg som Jackson bruker i tilfeller hvor reglene våre for snake_casing av camelCasedProperties ikke automatisk blir riktig

2025-12-17T13:50:51.227659Z

funksjonen vår for camel-to-snake gjør denne om til sales_to_external_b2_b_customers, i stedet for å "fikse" det ble det annotasjon

2025-12-17T13:51:05.280339Z

føler vi trenger en ny kanal: "hvordan overleve som Clojure-utvikler i the kingdom of nouns, og andre nyttige tips"

😁 1
teodorlu 2025-12-17T15:07:29.744949Z

dere napper i alle fall i en bit av hjernebarken min som sist var aktiv da jeg skrev Go på jobb! 😄

teodorlu 2025-12-17T15:07:38.339999Z

Jeg synes det passer fint inn her, jeg.