La différence entre un Seq et une Liste en Scala

J'ai vu dans de nombreux exemples, que, parfois, Seq est utilisé, tandis que d'autres fois c'est la Liste...

Est là toute la différence, autre que l'ancien étant un Scala type et la Liste à venir à partir de Java?

InformationsquelleAutor opensas | 2012-06-02
  1. 350

    En Java termes, Scala Seq serait de Java List, et Scala List serait de Java LinkedList.

    Noter que Seq est un trait, ce qui est équivalent à Java interface, mais avec l'équivalent de va-et-vient défenseur des méthodes. Scala List est une classe abstraite qui est prolongée par Nil et ::, qui sont, concrètement, les implémentations de List.

    Alors, où Java est List est un interface, Scala List est une mise en œuvre.

    Au-delà, Scala List est immuable, ce qui n'est pas le cas de LinkedList. En fait, Java n'a pas d'équivalent à l'immuable collections (lecture seule chose ne garantit que le nouvel objet ne peut pas être modifié, mais vous pouvez toujours changer l'ancien, et, par conséquent, la "lecture seule" l'un).

    Scala List est hautement optimisé par le compilateur et les bibliothèques, et c'est un type de données fondamental dans la programmation fonctionnelle. Cependant, il a des limites et c'est insuffisant pour la programmation parallèle. Ces jours-ci, Vector est un meilleur choix que List, mais l'habitude est difficile à briser.

    Seq est une bonne généralisation pour les séquences, donc si vous programmez à des interfaces, vous devez l'utiliser. Notez qu'il existe, en fait, trois d'entre eux: collection.Seq, collection.mutable.Seq et collection.immutable.Seq, et c'est ce dernier qui est le "défaut" importés dans l'étendue.

    Il y a aussi GenSeq et ParSeq. Les dernières méthodes de s'exécuter en parallèle, si possible, alors que le premier est un parent à la fois Seq et ParSeq, avoir une bonne généralisation pour quand le parallélisme d'un code n'a pas d'importance. Ils sont à la fois relativement récemment introduit, afin que les gens ne les utilisent pas encore beaucoup.

    • RE "Java n'a pas d'équivalent à l'immuable collections", bien que String n'est pas une collection, c'est un exemple de immuable classes familier pour les programmeurs Java.
    • C'est à côté de la question. J'ai été établissant des parallèles entre ce qui existe en Java et ce qui existe dans la Scala, et il n'est tout simplement pas le concept de la mutable/immuable collections en Java.
    • ParSeq est probablement peu utilisé en raison de ses cas d'utilisation sont limitées par la Loi d'Amdahl - votre speedup de parallélisme est limité si le temps d'exécution est dominé par son séquentielle bits. À utiliser avec précaution.
    • Java a effectivement l'équivalent de immuable collections. Ce n'est pas que le bien annoncé", mais il est là et quand vous utiliser des génériques fortement vous êtes susceptible de heurter certaines UnsupportedOperationException à cause de cela. Pour créer une liste immuable en Java que vous utilisez les Collections.unmodifiableList() et, de même, il existe d'autres méthodes pour les Ensembles, Cartes, etc. docs.oracle.com/javase/6/docs/api/java/util/...
    • Pas vrai. Si vous utilisez ces méthodes, vous obtenez quelque chose d'un objet qui permettra de lancer des exceptions sur les méthodes qui permettent de modifier, mais pas un immuable de l'objet. Si l'objet se modifie après la inmodifiable objet a été créé, le inmodifiable objet seront le reflet. Donc, inmodifiable, oui, immuable, non.
    • Eh bien, oui et non. Convenu que la langue n'est pas conçu pour un pur immuabilité. J'ai dit "équivalent" parce que dans la plupart des cas, il peut être utilisé selon les besoins. En fait, quand vous avez une collection générique paramètre d'un certain super-type avec extends et le béton de classe est passé d'un sous-type Java utilise un inmodifiable collection d'appliquer la méthode de réception de ne pas le modifier, évitant ainsi l'insertion d'un objet d'un autre sous-type. Oui le cas, vous êtes de mentionner vous permet de modifier les objets contenus dans la collection, mais pour des raisons de sécurité de type qu'il détient toujours.
    • La méthode de réception ne peut pas faire référence à la collection qu'il a reçu et suppose qu'il ne changera jamais, et il n'y a pas de taper dans la norme bibliothèque Java qui va garantir que -- c'est l'immuabilité. Ainsi, par exemple, que la méthode de réception ne peut pas garantir la sécurité des threads. Et cela ne touche même pas la persistance de caractéristiques activé par l'immuabilité. Sans cela, il ne peut pas être appelé "équivalent".
    • Si c'est fait allusion, il est sans doute intéressant de noter que la Scala de la Liste est O(n) pour l'élément de recherche à l'aide d'indices; donc, si vous avez besoin de non-séquentielle de recherche utiliser quelque chose d'autre, comme un IndexedSeq ou d'un Vecteur.
    • "Vecteur est un meilleur choix que la Liste" est trop général. Liste a de la constante de temps pour la tête, la queue et la faire précéder tandis que pour les Vecteurs ils sont "effectivement constante". J'aimerais utiliser la Liste des endroits où ces 3 opérations sont assez puisqu'il a un peu moins de frais généraux
    • Qui ignore la localité de référence. Oui, il est trop général, mais il arrive à être vrai, mais dans tous les cas de bord.
    • La localité de référence est un point valide ouais
    • Si Seq est un trait de caractère, alors pourquoi ne puis-je l'instancier? par exemple, pourquoi est - var x = Seq(1, 2, 3) juridique?
    • Le Seq objet hérite d'un apply méthode.
    • Parce que Seq est à la fois un caractère et un objet. Lorsque vous écrivez var x = Seq(1, 2, 3), vous appelez le apply méthode sur l'objet.
    • Est important de souligner que Seq est un paresseux opération de la représentation alors que la Liste est un béton de structure de données qui stocke les valeurs dans la mémoire. Je pense que c'est la plus grande différence.
    • n'est pas un paresseux opération. C'est une interface qui List met en œuvre.
    • vous avez entièrement raison. Je pense Immutable.js mais c'est de la Scala, mon mauvais

    InformationsquelleAutor Daniel C. Sobral
  2. 61

    Un Seq est un objet iterable qui a défini un ordre des éléments. Les séquences de fournir une méthode apply() pour l'indexation, allant de 0 jusqu'à la longueur de la séquence. Seq a de nombreuses sous-classes, y compris la File d'attente, Plage, Liste, Pile, et LinkedList.

    Un Liste est un Seq qui est mis en œuvre comme un immuable liste liée. C'est mieux utilisé dans les cas de dernier entré, premier sorti (LIFO) les profils d'accès.

    Voici la collection complète de classe de la hiérarchie de la Scala FAQ:

    La différence entre un Seq et une Liste en Scala

    InformationsquelleAutor Ceasar Bautista
  3. 18

    En Scala, une Liste hérite de Seq, mais met en œuvre Produit; ici est la bonne définition de Liste : 

    sealed abstract class List[+A] extends AbstractSeq[A] with Product with ...

    [Note: le réel définition est un peu plus complexe, afin d'adapter et de faire usage de la Scala est très puissant cadre de collecte.]

    InformationsquelleAutor zakelfassi
  4. 14

    Seq est un trait de caractère qui List met en œuvre.

    Si vous définissez votre conteneur Seq, vous pouvez utiliser un conteneur qui implémente Seq trait. 

    scala> def sumUp(s: Seq[Int]): Int = { s.sum }
sumUp: (s: Seq[Int])Int

scala> sumUp(List(1,2,3))
res41: Int = 6

scala> sumUp(Vector(1,2,3))
res42: Int = 6

scala> sumUp(Seq(1,2,3))
res44: Int = 6

    Noter que 

    scala> val a = Seq(1,2,3)
a: Seq[Int] = List(1, 2, 3)

    Est juste un raccourci pour:

    scala> val a: Seq[Int] = List(1,2,3)
a: Seq[Int] = List(1, 2, 3)

    si le type n'est pas spécifié, les données sous-jacentes de la structure par défaut List.

    InformationsquelleAutor Akavall