- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
2.8 collections: Return Type of MapLike#{mapValues, mapElements, filterKeys}
Sun, 2010-02-28, 11:06
These methods currently return the inferred type: Object with
collection.DefaultMap. This is problematic for two reasons: 1) it
exposes implementation details, and 2) it is not compatible with
immutable.Map.
Is this an oversight that could be corrected with the CanBuildFrom machinery?
Regards,
-jason
scala> val m = Map(1 -> 2)
m: scala.collection.immutable.Map[Int,Int] = Map((1,2))
scala> m map identity : Map[Int, Int]
res10: Map[Int,Int] = Map((1,2))
scala> m mapValues identity: Map[Int, Int]
:7: error: type mismatch;
found : java.lang.Object with scala.collection.DefaultMap[Int,Int]
required: Map[Int,Int]
m mapValues identity: Map[Int, Int]
^
scala> m filterKeys Function.const(true) : Map[Int, Int]
:7: error: type mismatch;
found : java.lang.Object with scala.collection.DefaultMap[Int,Int]
required: Map[Int,Int]
m filterKeys Function.const(true) : Map[Int, Int]
^
scala> m mapValues identity: collection.Map[Int, Int]
res13: scala.collection.Map[Int,Int] = Map((1,2))
Sun, 2010-02-28, 19:57
#2
Re: 2.8 collections: Return Type of MapLike#{mapValues, mapEle
Overrides in immutable.MapLike would be sufficient, and IMO,
worthwhile to avoid potential confusion between the three instances of
the class Map.
Forgetting backwards compatibility for a moment, perhaps it would be
more consistent if the lazy methods on Maps were done through Views.
(Currently, MapLike.view returns an IterableView[A, B].)
-jason
trait MapLike[A, +B, This...] .. {
override def view: MapView[...]
class MapView(delegate: Map) extends IterableView{
// lazy operations, return static collection type.
def mapElements: Map
def filterKeysElements: Map
}
// delegate to Traversable map/filter
def mapElements[AA, That](f: A => AA)(implicit cbf: CanBuildFrom[...]): That
def filterKeys(f: V => VV): Repr
}
On Sun, Feb 28, 2010 at 6:07 PM, martin odersky wrote:
> On Sun, Feb 28, 2010 at 11:06 AM, Jason Zaugg wrote:
>> These methods currently return the inferred type: Object with
>> collection.DefaultMap. This is problematic for two reasons: 1) it
>> exposes implementation details, and 2) it is not compatible with
>> immutable.Map.
>
> Agreed on 1). filterKeys (and also mapValues) should return Maps not
> DefaultMaps.
>
> Only half agreed on 2). The problem is that both operations forward to
> the original map. So if the original map is mutable, it would be falso
> to claim that the filtered map is immutable. However, one could
> consider duplicating filterKeys and mapValues in immutable.MapLike,
> where they could then return immutable maps.
>
> Cheers
>
> -- Martin
>
Sun, 2010-02-28, 20:07
#3
Re: 2.8 collections: Return Type of MapLike#{mapValues, mapEle
I meant to say, "the three types named Map".
On Sun, Feb 28, 2010 at 7:56 PM, Jason Zaugg wrote:
> [snip] to avoid potential confusion between the three instances of
> the class Map.
Mon, 2010-03-01, 01:07
#4
Re: 2.8 collections: Return Type of MapLike#{mapValues, mapEle
On Sun, Feb 28, 2010 at 7:56 PM, Jason Zaugg wrote:
> Overrides in immutable.MapLike would be sufficient, and IMO,
> worthwhile to avoid potential confusion between the three instances of
> the class Map.
>
> Forgetting backwards compatibility for a moment, perhaps it would be
> more consistent if the lazy methods on Maps were done through Views.
> (Currently, MapLike.view returns an IterableView[A, B].)
>
You are right. I did not have the time to figure out how to extend views
to maps and sets. if someone wants to take this up, please do!
On Sun, Feb 28, 2010 at 11:06 AM, Jason Zaugg wrote:
> These methods currently return the inferred type: Object with
> collection.DefaultMap. This is problematic for two reasons: 1) it
> exposes implementation details, and 2) it is not compatible with
> immutable.Map.
Agreed on 1). filterKeys (and also mapValues) should return Maps not
DefaultMaps.
Only half agreed on 2). The problem is that both operations forward to
the original map. So if the original map is mutable, it would be falso
to claim that the filtered map is immutable. However, one could
consider duplicating filterKeys and mapValues in immutable.MapLike,
where they could then return immutable maps.
Cheers