2.8 collection feedback

On Fri, Jun 19, 2009 at 7:58 PM, Blair Zajac wrote:
> I spent some time with the new collections and here's a few things I
> noticed. Before that, the new collections look great.  Getting an instance
> of the collection class back that you started with makes it so much easier
> to use.
>
> I've been doing a lot with SortedMap and SortedSet.  This is with
> 2.8.0.r18050-b20090618020144.
>
> 1) Filtering a keySet fails in 2.8 but works in 2.7.4
>
> var tm = new scala.collection.immutable.TreeMap[Int,Int]
> for (i <- 0 to 100) tm = tm.insert(i, i)
> tm.keySet.filter(_ < 40)
>
> This throws a java.lang.UnsupportedOperationException in 2.8.
>
> http://lampsvn.epfl.ch/trac/scala/ticket/2075
>
yes, we need to fix that by implementing SetViews. Not done yet. I am
running our of time to do it myself, so patches from whomever would be
welcome!

> 2) Iterable#take() is deprecated in 2.7.x so that taking from a HashSet
> gives a warning.  This makes sense given that there's no ordering in a
> HashSet:
>
> scala> val s = new scala.collection.mutable.HashSet[Int]
> s: scala.collection.mutable.HashSet[Int] = Set()
>
> scala> s.take(0)
> :6: warning: method take in trait Iterable is deprecated
>       s.take(0)
>         ^
>
> However, in 2.8 there is no warning.  Should this be opened as a ticket?
>
No, we decided against fixing ordering problems in the type system.
The collections classes do not distinguish between ordered and
unordered collections. Even for unordered collections, take is useful,
if you understand what it does. It means "give me some arbitrary N
elements".

> 3) How does one tell the behavior of a collection class that is a result of
> a method on another collection instance.  For example, filtering a TreeMap
> on its keys;
>
> scala> var tm = new scala.collection.immutable.TreeMap[Int,Int]
> tm: scala.collection.immutable.TreeMap[Int,Int] = Map()
>
> scala> for (i <- 0 to 100) tm = tm.insert(i, i)
>
> scala> tm.filterKeys(_ < 40)
> res2: java.lang.Object with scala.collection.DefaultMap[Int,Int] = Map(0 ->
> 0, 1 -> 1, 2 -> 2, 3 -> 3, 4 -> 4, 5 -> 5, 6 -> 6, 7 -> 7, 8 -> 8, 9 -> 9,
> 10 -> 10, 11 -> 11, 12 -> 12, 13 -> 13, 14 -> 14, 15 -> 15, 16 -> 16, 17 ->
> 17, 18 -> 18, 19 -> 19, 20 -> 20, 21 -> 21, 22 -> 22, 23 -> 23, 24 -> 24, 25
> -> 25, 26 -> 26, 27 -> 27, 28 -> 28, 29 -> 29, 30 -> 30, 31 -> 31, 32 -> 32,
> 33 -> ...
>
> I don't know if the scala.collection.DefaultMap preserves the ordering in
> the original TreeMap.  It looks like it does, but without going into the
> code, I can't trust that I still have a TreeMap here.
>
You should have a view of a TreeMap, not a TreeMap, per se. filterKeys
is defined to be lazy. For filter it's different. Here you should
indeed get a TreeMap.

> 4) For consistency with ++ and --, should the new & operator, which replaces
> **, on sets be named &&?
>
& is chosen for conistency with bitwise int operation. && means
short-circuiting, which is not what we want to imply.

Cheers

Thanks Martin for answering the questions quickly.

Blair

martin odersky wrote:
> On Fri, Jun 19, 2009 at 7:58 PM, Blair Zajac wrote:
>> I spent some time with the new collections and here's a few things I
>> noticed. Before that, the new collections look great. Getting an instance
>> of the collection class back that you started with makes it so much easier
>> to use.
>>
>> I've been doing a lot with SortedMap and SortedSet. This is with
>> 2.8.0.r18050-b20090618020144.
>>
>> 1) Filtering a keySet fails in 2.8 but works in 2.7.4
>>
>> var tm = new scala.collection.immutable.TreeMap[Int,Int]
>> for (i <- 0 to 100) tm = tm.insert(i, i)
>> tm.keySet.filter(_ < 40)
>>
>> This throws a java.lang.UnsupportedOperationException in 2.8.
>>
>> http://lampsvn.epfl.ch/trac/scala/ticket/2075
>>
> yes, we need to fix that by implementing SetViews. Not done yet. I am
> running our of time to do it myself, so patches from whomever would be
> welcome!
>
>> 2) Iterable#take() is deprecated in 2.7.x so that taking from a HashSet
>> gives a warning. This makes sense given that there's no ordering in a
>> HashSet:
>>
>> scala> val s = new scala.collection.mutable.HashSet[Int]
>> s: scala.collection.mutable.HashSet[Int] = Set()
>>
>> scala> s.take(0)
>> :6: warning: method take in trait Iterable is deprecated
>> s.take(0)
>> ^
>>
>> However, in 2.8 there is no warning. Should this be opened as a ticket?
>>
> No, we decided against fixing ordering problems in the type system.
> The collections classes do not distinguish between ordered and
> unordered collections. Even for unordered collections, take is useful,
> if you understand what it does. It means "give me some arbitrary N
> elements".
>
>> 3) How does one tell the behavior of a collection class that is a result of
>> a method on another collection instance. For example, filtering a TreeMap
>> on its keys;
>>
>> scala> var tm = new scala.collection.immutable.TreeMap[Int,Int]
>> tm: scala.collection.immutable.TreeMap[Int,Int] = Map()
>>
>> scala> for (i <- 0 to 100) tm = tm.insert(i, i)
>>
>> scala> tm.filterKeys(_ < 40)
>> res2: java.lang.Object with scala.collection.DefaultMap[Int,Int] = Map(0 ->
>> 0, 1 -> 1, 2 -> 2, 3 -> 3, 4 -> 4, 5 -> 5, 6 -> 6, 7 -> 7, 8 -> 8, 9 -> 9,
>> 10 -> 10, 11 -> 11, 12 -> 12, 13 -> 13, 14 -> 14, 15 -> 15, 16 -> 16, 17 ->
>> 17, 18 -> 18, 19 -> 19, 20 -> 20, 21 -> 21, 22 -> 22, 23 -> 23, 24 -> 24, 25
>> -> 25, 26 -> 26, 27 -> 27, 28 -> 28, 29 -> 29, 30 -> 30, 31 -> 31, 32 -> 32,
>> 33 -> ...
>>
>> I don't know if the scala.collection.DefaultMap preserves the ordering in
>> the original TreeMap. It looks like it does, but without going into the
>> code, I can't trust that I still have a TreeMap here.
>>
> You should have a view of a TreeMap, not a TreeMap, per se. filterKeys
> is defined to be lazy. For filter it's different. Here you should
> indeed get a TreeMap.
>
>> 4) For consistency with ++ and --, should the new & operator, which replaces
>> **, on sets be named &&?
>>
> & is chosen for conistency with bitwise int operation. && means
> short-circuiting, which is not what we want to imply.
>
> Cheers
>