Kotlin et Immuable Collections?

Kotlin de List de la bibliothèque standard est en lecture seule:

interface List<out E> : Collection<E> (source)

Un générique collection ordonnée d'éléments. Les méthodes de cette interface
en charge uniquement un accès en lecture seule à la liste; accès en lecture/écriture
pris en charge par la MutableList interface.

Paramètres

E - le type des éléments contenus dans la liste.

Comme mentionné, il y a aussi le MutableList

interface MutableList<E> : List<E>, MutableCollection<E> (source)

Un générique collection ordonnée d'éléments qui supporte l'ajout et la
la suppression d'éléments.

Paramètres

E - le type des éléments contenus dans la liste.

Pour cette raison, Kotlin applique readonly comportement, grâce à ses interfaces, au lieu de lancer des Exceptions de l'exécution comme Java par défaut des implémentations ne.

De même, il est un MutableCollection, MutableIterable, MutableIterator, MutableListIterator, MutableMap, et MutableSet, voir la stdlib de la documentation.

Que vous voyez dans d'autres réponses, Kotlin a readonly interfaces mutable collections qui vous permettent de visualiser une collection à travers une lecture seule lentille. Mais la collection ne peut être contournée par coulage ou manipulées à partir de Java. Mais en coopérative Kotlin code c'est bien, la plupart des utilisations n'ont pas besoin de vraiment immuable collections et si votre équipe évite les jette à la mutable forme de la collection, alors peut-être que vous n'avez pas besoin pleinement immuable collections.

La Kotlin collections permettent à la fois de copie sur le changement des mutations, ainsi que des paresseux, des mutations. Donc, pour répondre à une partie de vos questions, des choses comme filter, map, flatmap, les opérateurs + - tous de créer des copies lorsqu'il est utilisé contre les non paresseux collections. Lorsqu'il est utilisé sur un Sequence ils modifient les valeurs de la collection car il est accessible et de continuer à être paresseux (résultant dans un autre Sequence). Bien que, pour un Sequence, l'appel de n'importe quoi comme toList, toSet, toMap sera le résultat final de la copie est faite. Par la convention de nommage de presque tout ce qui commence par to est de faire une copie.

En d'autres termes, la plupart des opérateurs vous retourner le même type que vous avez commencé avec, et si c'est de type "lecture seule", puis vous recevrez une copie. Si ce type est paresseux, alors vous aurez paresseusement appliquer la modification jusqu'à ce que vous demande la collection dans son intégralité.

Certaines personnes veulent eux pour d'autres raisons, telles que le traitement en parallèle. Dans ces cas, il pourrait être préférable de regarder vraiment haut de la performance des collections conçues pour ces fins. Et de les utiliser uniquement dans les cas, pas dans tous les cas généraux.

Dans la JVM monde, il est difficile d'éviter d'interopérabilité avec les bibliothèques qui veulent standard de Java collections, et de la conversion vers ou à partir de ces collections ajoute beaucoup de douleur et de frais généraux pour les bibliothèques qui ne prennent pas en charge les interfaces communes. Kotlin donne un bon mélange de l'interopérabilité et de l'absence de conversion, avec readonly protection par contrat.

Donc, si vous ne pouvez pas éviter de vouloir immuable collections, Kotlin fonctionne facilement avec quoi que ce soit à partir de la JVM de l'espace:

• Goyave (https://github.com/google/guava)
• Dexx un port de la Scala collections de Java (https://github.com/andrewoma/dexx) avec Kotlin aides (https://github.com/andrewoma/dexx/blob/master/kollection/README.md)
• Eclipse Collections (anciennement GS-Collections) une très haute performance, JDK compatible, le plus performant de traitement parallèle avec immuable et changeante des variations (à la maison: https://www.eclipse.org/collections/ et Github: https://github.com/eclipse/eclipse-collections)
• PCollections (http://pcollections.org/)

Aussi, le Kotlin équipe travaille sur Immuable Collections de mode natif pour Kotlin, cet effort peut être vu ici:
https://github.com/Kotlin/kotlinx.collections.immutable

Il ya beaucoup d'autres de la collection de cadres pour tous les différents besoins et contraintes, Google est votre ami pour les trouver. Il n'y a aucune raison pour que le Kotlin équipe doit se réinventer pour sa bibliothèque standard. Vous avez beaucoup d'options, et ils se spécialisent dans divers domaines tels que la performance, l'utilisation de la mémoire, pas de la boxe, l'immuabilité, etc. "Le choix est Bon" ... donc certains autres: HPCC, HPCC-RT, FastUtil, Koloboke, Trove et de plus...

Il y a même des efforts comme Pure4J qui, depuis Kotlin prend en charge les Annotations de traitement, peut-être que peut avoir un port de Kotlin pour les mêmes idéaux.

REMARQUE: Cette réponse est ici, parce que le code est simple et open-source et vous pouvez utiliser cette idée pour faire de votre collection que vous créez immuable. Il n'est pas conçu comme une annonce de la bibliothèque.

Dans Klutter bibliothèque, sont de nouveaux Kotlin Immuable des wrappers qui utilisent Kotlin délégation pour l'envelopper d'un existant Kotlin interface de collecte avec une couche de protection sans aucun gain de performance. Il n'y a alors aucun moyen de lancer la collection, son itérateur, ou d'autres collections, il pourrait revenir dans quelque chose qui pourrait être modifié. Ils deviennent en effet Immuable.

Klutter 1.20.0 libérés qui ajoute immuable protecteurs pour les collections existantes, basées sur une DONC réponse par @miensol offre une légèreté et un délégué autour des collections qui empêche toute l'avenue de la modification, y compris un casting pour une mutable type puis de modifier. Et Klutter va une étape plus loin en protégeant sous collections telles que l'itérateur, listIterator, entrySet, etc. Toutes ces portes sont fermées et à l'aide de Kotlin délégation pour la plupart des méthodes que vous prenez pas frappé de la performance. Appelez simplement myCollection.asReadonly() (protéger) ou myCollection.toImmutable() (copier puis protéger) et le résultat est le même interface, mais protégé.

Voici un exemple de code montrant comment simplement la technique est, par gros de délégation de l'interface de la classe réelle tout en substituant la mutation des méthodes et des sous-collections renvoyées sont enveloppés à la volée.

/**
 * Wraps a List with a lightweight delegating class that prevents casting back to mutable type
 */
open class ReadOnlyList <T>(protected val delegate: List<T>) : List<T> by delegate, ReadOnly, Serializable {
    companion object {
        @JvmField val serialVersionUID = 1L
    }

    override fun iterator(): Iterator<T> {
        return delegate.iterator().asReadOnly()
    }

    override fun listIterator(): ListIterator<T> {
        return delegate.listIterator().asReadOnly()
    }

    override fun listIterator(index: Int): ListIterator<T> {
        return delegate.listIterator(index).asReadOnly()
    }

    override fun subList(fromIndex: Int, toIndex: Int): List<T> {
        return delegate.subList(fromIndex, toIndex).asReadOnly()
    }

    override fun toString(): String {
        return "ReadOnly: ${super.toString()}"
    }

    override fun equals(other: Any?): Boolean {
        return delegate.equals(other)
    }

    override fun hashCode(): Int {
        return delegate.hashCode()
    }
}

Avec helper extension de fonctions pour le rendre facile d'accès:

/**
 * Wraps the List with a lightweight delegating class that prevents casting back to mutable type,
 * specializing for the case of the RandomAccess marker interface being retained if it was there originally
 */
fun <T> List<T>.asReadOnly(): List<T> {
    return this.whenNotAlreadyReadOnly {
        when (it) {
            is RandomAccess -> ReadOnlyRandomAccessList(it)
            else -> ReadOnlyList(it)
        }
    }
}

/**
 * Copies the List and then wraps with a lightweight delegating class that prevents casting back to mutable type,
 * specializing for the case of the RandomAccess marker interface being retained if it was there originally
 */
@Suppress("UNCHECKED_CAST")
fun <T> List<T>.toImmutable(): List<T> {
    val copy = when (this) {
        is RandomAccess -> ArrayList<T>(this)
        else -> this.toList()
    }
    return when (copy) {
        is RandomAccess ->  ReadOnlyRandomAccessList(copy)
        else -> ReadOnlyList(copy)
    }
}

Vous pouvez voir l'idée et de l'extrapoler à créer les classes manquantes à partir de ce code qui reprend les modèles pour d'autres référencé types. Ou d'afficher le code complet ici:

https://github.com/kohesive/klutter/blob/master/core-jdk6/src/main/kotlin/uy/klutter/core/common/Immutable.kt

Et avec des tests montrant quelques-uns des trucs que les modifications autorisées avant, mais plus maintenant, avec l'bloqué jette et des appels à l'aide de ces gestionnaires.

https://github.com/kohesive/klutter/blob/master/core-jdk6/src/test/kotlin/uy/klutter/core/collections/TestImmutable.kt