Hoe werken standaardargumenten en benoemde parameters in Kotlin? Vertel over de verschillen met Java, nuances in argumentoverdracht, compilatie met overload-methoden, en de volgorde van benoemde en positionele parameters. Geef een voorbeeld.

Antwoord.

Kotlin ondersteunt standaardwaarden (default arguments) en benoemde parameters (named parameters), wat veel flexibiliteit biedt in vergelijking met Java.

Belangrijkste punten:

• In Kotlin kunnen functieparameters standaardwaarden hebben:

  fun greet(name: String = "User", greeting: String = "Hello") {
      println("$greeting, $name!")
  }

• Je kunt een functie aanroepen met alleen de benodigde parameters — de overige worden automatisch opgevuld.
• Benoemde parameters maken het mogelijk om expliciet de naam van het argument op te geven — vooral handig als een functie veel parameters heeft:

  greet(greeting = "Hallo") // -> Hallo, User!

• Je kunt gewone (positionele) en benoemde parameters combineren, zolang benoemde parameters niet halverwege de aanroep worden gebruikt.
• In tegenstelling tot Java (waar je overload maakt voor elke combinatie), compileert Kotlin standaardargumenten naar overload-methoden alleen voor interoperabiliteit met Java, wat in Kotlin zelf niet zichtbaar is.

Nuances:

• Na het gebruik van een benoemd argument moeten alle volgende argumenten ook benoemd zijn.
• Voor het gebruik van functies met standaardparameters vanuit Java kunnen annotaties @JvmOverloads nodig zijn.

Misleidende vraag.

Mag je positionele en benoemde argumenten in willekeurige volgorde mengen bij het aanroepen van een functie in Kotlin?

Juiste antwoord: Nee, nadat je ten minste één benoemd argument hebt opgegeven, moeten alle volgende ook benoemd zijn. Overtreding hiervan zal een compilatiefout veroorzaken.

// Onjuist
greet(greeting = "Hoi", "Ivan") // Fout!

// Juist
greet("Ivan", greeting = "Hoi")
greet(name = "Ivan", greeting = "Hoi")

Voorbeelden van echte fouten door gebrek aan kennis van de nuances van het onderwerp.

---

Verhaal

Het team heeft een Kotlin-module geïntegreerd met een legacy Java-project en vergat de annotatie @JvmOverloads toe te voegen voor de functie met standaardparameters. Als gevolg hiervan zag de Java-code de benodigde overload-methoden niet — er ontstonden runtime-fouten bij het aanroepen.

---

Verhaal

Bij het refactoren met behulp van benoemde parameters verwisselde de ontwikkelaar per ongeluk de argumenten — bij een latere naamswijziging van de parameters bleef dit onopgemerkt (de typificatie was niet verbroken, maar de semantiek van de aanroep was veranderd!). Dit leidde tot vreemde bugs in de UI-logica, die niet meteen werden ontdekt.

---

Verhaal

Een van de ontwikkelaars, in een poging de leesbaarheid te verbeteren, mengde positionele en benoemde argumenten halverwege de aanroep. De code compileerde niet, maar het team begreep moeilijk wat precies het probleem was — omdat ze dit vaak in andere talen tegenkwamen en soortgelijk gedrag van Kotlin verwachtten.