Morn!
Mrn
Morgen!
Morn!
Morn!
Morn!
Morn
god morgen!
god morgen!
Morn!
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]))
}Om ikke annet så vaksineres vi fint mot eventuell trang til å bytte programmeringsspråk. 😄
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:
)
)
)
)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
Rich Hickey skriker at maps må være maps
jepp, men mangelen på keywords gjør at maps ikke er en god løsning i java/kotlin. Det blir en PITA
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!
Det er kanskje en løsning. Manglende namespacing kommer sikkert til å savnes, dog.
dette skriker kanskje "Clojure i Kotlin", men vi har en del typer som dette:
Map<KProperty1<B2BCustomerEntityData, Any?>, Any?>da kan vi lage maps hvor nøklene er kjent type i dataklasse, f.eks:
mapOf(B2BCustomerEntityData::countryIsoCode to "NOK")verdien blir naturligvis ikke typesikker, men vi bruker det til å ha litt mere enn null typesikkerhet på "partials" av dataklasser
Kult! Hvordan er det med serialisering av KProperty1? Går det greit?
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
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
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
føler vi trenger en ny kanal: "hvordan overleve som Clojure-utvikler i the kingdom of nouns, og andre nyttige tips"
dere napper i alle fall i en bit av hjernebarken min som sist var aktiv da jeg skrev Go på jobb! 😄
Jeg synes det passer fint inn her, jeg.