2009-06-04 5 views
1

Pourquoi ne puis-je pas ajouter à un scala.collection.Map? Il semble que ce trait est assez inutile sans cette fonctionnalité.scala collection.Map ne peut pas être ajouté à

Impossible de remplacer la méthode ++ dans Iterable et de réduire le type de retour à Map?

P.S. Je ne veux pas dire qu'il devrait être mutable, juste qu'il devrait être en mesure de retourner un nouveau Map avec un mappage ajouté (ou mappages), le même que immutable.Map.

Répondre

6

Je vais laisser la réponse originale ci-dessous, bien que ce soit à peu près incorrect, car je n'ai pas bien compris la question.

La bibliothèque de collections actuelle de Scala impose pratiquement différentes méthodes d'ajout pour mutable/immutable, probablement dans l'espoir de préciser dans le code source quel type de collection est utilisé. Comme on l'a dit, cette question est en train d'être révisée en 2.8, et cette prémisse est en train de disparaître. Cela étant, les classes abstraites ne fournissent pas les méthodes que vous envisagez, car elles peuvent exister pour immuable mais pas pour mutable, et vice versa. Ou ils peuvent avoir le même nom, mais différentes implémentations.

Et, par conséquent, il serait impossible de les fournir dans la classe de base.

Mais, de plus, notez que, de cette façon, si vous recevez un scala.collection.map, vous ne pouvez pas le vider en le traitant comme mutable lorsque vous avez reçu un immutable, ou vice versa.

Et, maintenant, pour la mauvaise réponse. :)

Vous pouvez (non, vous ne pouvez pas - le code ci-dessous utilise scala.collection.imutable.Map).

scala> val x = Map(1 -> 'a', 2 -> 'b') 
x: scala.collection.immutable.Map[Int,Char] = Map(1 -> a, 2 -> b) 

scala> x ++ Map(3 -> 'c') 
res5: scala.collection.immutable.Map[Int,Char] = Map(1 -> a, 2 -> b, 3 -> c) 

scala> var y = x 
y: scala.collection.immutable.Map[Int,Char] = Map(1 -> a, 2 -> b) 

scala> y += (3 -> 'c') 

scala> y 
res7: scala.collection.immutable.Map[Int,Char] = Map(1 -> a, 2 -> b, 3 -> c) 

scala> x + (3 -> 'c') 
res8: scala.collection.immutable.Map[Int,Char] = Map(1 -> a, 2 -> b, 3 -> c) 
+0

Hmmmm. Il me semble qu'en créant deux types tous deux appelés Map, les deux prolongeant les collections.Carte mais se comportant de manière complètement différente, les créateurs de la bibliothèque Scala ont déjà créé la situation dans laquelle je peux "bousiller en traitant [quelque chose] comme mutable quand [il est] immuable". S'ils ne voulaient pas que ce soit le cas, ils ne devraient pas avoir un supertype partagé! –

+0

Ce sont les deux cartes dans le sens où ce sont les deux collections auxquelles les clés peuvent accéder. C'est une carte. Et, comme vous l'avez découvert vous-même, les cours ont été écrits pour que vous ne vous foiriez pas. –

0

Je suppose que: Si vous avez une certaine collection et que vous devez fournir une façade de carte en lecture seule pour d'autres, cette caractéristique convient au travail tel quel. Si vous incluez l'addition il n'y aurait pas de conception orthogonale puisqu'on aurait alors besoin d'une interface de carte en lecture seule. D'un autre côté, si l'opération ++ est nécessaire dans une interface générique, elle ne conviendra pas aux implémentations mutables et immuables. Par exemple. si la collection mutable renvoyait self à l'addition il ne serait pas évident ce qui se passe juste en regardant l'interface.

+0

Mais l'immuable Map * définit * un opérateur ++! C'est mon point! Il renvoie une (nouvelle) carte avec le mapping ajouté. Si utiliser scala.collection.Map est implicitement une carte immuable, je ne vois pas pourquoi il ne peut pas avoir la fonctionnalité d'un. Après tout, ils vont à peine changer le Predef, n'est-ce pas? –

+0

En effet, comme David Hall a souligné ma conjecture pourrait ne pas tenir. scala.collections.Map hérite de scala.collections.generic.MapTemplate qui fournit une opération "++" (immuable). Voir cependant les annotations de dépréciation sur les méthodes ++ dans MutableMapTemplate (qui est héritée par scala.collections.mutable.Map) –

+0

(j'ai regardé les sources de tronc de svn 2.8) –

1

La bibliothèque de collections Scala est actuellement très imparfaite. 2.8 (en raison de la publication dans un mois ou deux) a une bibliothèque de collections complètement remanié que je crois a le comportement que vous recherchez.

Questions connexes