Context parameters and API design

Dag 2, 22. mai 2026 · kl 14:00 · Alejandro Serrano Mena · 📋 i programmet · 🌐 offisiell beskrivelse

Context parameters ble stabilisert i Kotlin 2.4 og skrives foran signaturen som context(users: UserService) fun User.getFriends(), slik at verdien tres implisitt gjennom kallkjeden uten manuell videresending på hvert nivå. Serrano Mena bruker en filmmetafor («spotlight-prinsippene», illustrert med Grease og Ocean’s 11) for å skille hovedroller (mottakere, this) fra biroller (context parameters): en mottaker kan fylle et kontekstargument implisitt, men aldri motsatt, og Kotlin begrenser bevisst antall «hovedroller» på scenen for å unngå at det implisitte scopet blir uoversiktlig, slik det tidligere context receivers-forslaget led under. Context-argumenter kan også oppgis eksplisitt i hjørnetilfeller, og context(...)-funksjonen lar deg refinere konteksten lokalt, for eksempel bytte ut loggeren med en kopi med høyere loggnivå for en ikke-kritisk seksjon.

Context parameters egner seg best i to mønstre: usynlige kontekster som Logger eller Arrows Raise (der understreknavnet _ kan brukes), og «leaf-only»-tjenester som UserService, altså typesikker, «fattigmanns» dependency injection, transaksjons-, logg- og autorisasjonsscoper. Trenger man mange avhengigheter, anbefaler han å starte med flere vanlige context parameters fremfor et gudobjekt. Det såkalte «holder-mønsteret» med små interfaces og interface-delegering (prøvd internt i Kotlin-kompilatoren) finnes, men er tungt og bør vurderes to ganger. Byggere og DSL-er som buildList eller kotlinx.html skal derimot forbli mottakere, for objektet som bygges er hovedrollen på scenen, og bruk av DslMarker og nøsting bryter ellers sammen. Er man i tvil, er det trygt å starte med mottaker: migrering fra mottaker til context parameter er bevisst godt støttet, ikke motsatt vei.

Han viste også «bridge»-mønsteret (teknikken som gjør kontekster usynlige for kalleren), men advarte mot å definere usynlige kontekster og understrekparametre uten god grunn, og mot å konvertere alt fra mottakere til context parameters bare fordi språket nå tillater det. Fra spørsmålsrunden: valgfrie context parameters er bevisst utelatt (nullable typer er workarounden), det er ingen kobling til CoroutineContext (men en KEEP for å auto-injisere den i suspend-funksjoner er publisert), og i motsetning til Scalas implicits gjør Kotlin bevisst ingen kompleks resolusjon: ved tvetydighet må man være eksplisitt. Hovedbudskapet til API-designere er derfor konseptuelt, ikke syntaktisk: velg mottaker når verdien fortjener rampelyset, og context parameter når den bare skal støtte fra kulissene. Godt foredrag om en nyttig ny språkfunksjon: filmmetaforen gjør valget mellom mottaker og context parameter lett å huske.

Tags: Kotlin 2.4 · Context parameters · API-design · DSL · Språkdesign

📹 Context parameters and API design – Alejandro Serrano Mena

← 1300 Eval-Driven Development · 1515 gRPC, Made for Kotlin →