Ergebnisse des Kotlin-Survey

Die Zukunft von Kotlin: Diese Features wünscht sich die Community

Hartmut Schlosser

Die Zukunft von Kotlin sieht rosig aus. Vieles deutet darauf hin, dass sich die Programmiersprache als feste Größe im Zirkus der JVM-Sprachen etablieren wird, etwa Googles jüngstes Bekenntnis zu Kotlin und die Integration der Sprache in die IDE Android Studio. Wie es nun konkret mit den Features in Kotlin weiter gehen soll, haben die Sprachenentwickler von JetBrains in einem Survey ermittelt.

In der Umfrage war die Community aufgerufen, aus 20 neuen Features die jeweils 3 am meisten gewünschten auszusuchen. Zudem galt es, ein Feature aus der Liste als unerwünscht zu streichen.

Dabei standen die folgenden 20 Features zur Auswahl:

  • Multi-catch
  • Overloadable Operations | and &
  • Short notation for enum constants
  • Private members accessible from tests
  • Support package-private visibility
  • Collection Literals
  • Collection comprehensions
  • Slices for lists and arrays
  • Inline classes / Value classes
  • Format strings
  • Optional (trailing) commas
  • Unsigned arithmetic
  • SAM conversions for Kotlin interfaces
  • Annotations for static analyses
  • Destructureing assignments
  • Use invokedynamic to compile Kotlin
  • Static membersfor Kotlin classes
  • Truly immutable data
  • Subject variable in when
  • Vararg-like treatment of data classes

Mit deutlichem Abstand haben es drei Features auf die Wunschliste der Community geschafft:

  • Collection literals
  • SAM conversions for Kotlin interfaces
  • Truly immutable data

Quelle: https://blog.jetbrains.com/kotlin/2017/06/kotlin-future-features-survey-results/

Schauen wir uns die Wunschfeatures der Community einmal genauer an:

Collection literals

Collections werden in Kotlin derzeit durch den Aufruf von Library-Funktionen erzeugt, beispielsweise listOf(1, 2, 3) oder mapOf(“foo” to “bar”, “baz” to “roo”). Mit Collection-Literalen könnte hierfür eine spezielle Syntax eingeführt werden. Das Kotlin-Entwicklerteam stellt sich das in etwa so vor: [1, 2, 3] oder [“foo” = “bar”, “baz” = “roo”].

SAM conversions for Kotlin interfaces

SAM steht für Single Abstract Method. Interfaces, die über eine einzige abstrakte Methnode verfügen, können einfach via Lambda-Ausdrücke implementiert werden. In Kotlin werden solche SAM-Konversionen in Lambdas bereits für Java-Interfaces durchgeführt.

Momentan können jedoch in Kotlin implementierten Interfaces nicht direkt Lambdas zugewiesen werden. Das könnte sich durch eine neue Syntax ändern:

Alt:

interface Action <T> {

fun run (data: T)
}

Neu:

val action: Action<T> = { data -> log(„data: $data“) }

Truly immutable data

In Kotlin existieren bereits unveränderliche Variablen (**val**’s). Doch es gibt keinen Sprachmechanismus, der die echte Unveränderlichkeit des Zustandes garantieren würde. Wenn etwa ein val ein veränderliches Objekt referenziert, kann sein Inhalt variiert werden.

Val myVal = arrayListOf(1)
myVal.add(2) // mutation

Was deshalb wünschenswert wäre, ist ein Modifizierer-Konstrukt wie **readonly**/**immutable** für alle Typen, beispielsweise:

class Foo(var v: Int)

immutable class Bar(val foo: Foo) // error: mutable reference from immutable
class

Kotlins Zukunft

Auf dem Kotlin-Blog kommentiert Andrey Breslav vom Kotlin-Entwicklerteam, dass die beiden ersten, also Collection-Literale und SAM-Konversionen für Kotlin-Interfaces, in näherer Zukunft zu machen wären. Unveränderliche Daten seien zwar wünschenswert, aber auch sehr schwer zu implementieren. Das gezeigte Beispiel habe lediglich provisorischen Charakter – es müsse sich bei vielen Features erst zeigen, ob sie überhaupt pragmatisch und elegant in die Sprache integriert werden können.

Gut sieht es laut Breslav noch für Multi-catch Blöcke aus, die folgende Gestalt annehmen könnten:


try {

// some code

} catch (e: ExceptionA|ExceptionB) {

log(e);

throw e;

}

Schlecht stehen die Karten indes für die Idee, Private Members von Tests aus zugänglich zu machen. Dieser Feature-Vorschlag war von der Community nämlich am schlechtesten bewertet worden:

Quelle: https://blog.jetbrains.com/kotlin/2017/06/kotlin-future-features-survey-results/

Details zu den Feature-Vorschlägen und den Umfrageergebnissen finden sich auf dem Kotlin-Blog.

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.