2.8 collections

[Ismael Juma]

Hi,

<Kieron.Wilkinson <at> paretopartners.com> writes:

>
> On Tue, May 19, 2009 at 5:06 PM,  <Kieron.Wilkinson <at> paretopartners.com>
> wrote:
> > I'm not sure I understand the value of the WeakHashSet and WeakHashMap
> > implementations, but perhaps that is just because I have never found a
> > problem that is well solved using a java.util.WeakHashMap (I've never
> had
> > to do canonical mappings as suggested by the WeakReference Javadocs). I
> > personally find soft referenced collections far more useful (for
> caching),

Soft references are more useful for caching, sure, but weak references are also
very useful.

> > and so I'll ask - would it be a better to instead provide something more
> > configurable, something like Google Collection's MapMaker which, among
> > other things, generates a ConcurrentMap with flexible reachability of
> > values, weak or soft?

Thankfully, if we use something similar to MapMaker we have the option of either.

> On Tue, May 19, 2009 at 5:12 PM, martin odersky <martin.odersky <at> epfl.ch>
> wrote:
> > I am not enough of an expert on this, unfortunately. I someone wants
> > to contribute better soft referenced collections, great!
>
> Sadly, neither am I. I'd be happy to have a go, but being a beginner in
> Scala, I fully expect whatever I produced would be far from idiomatic.
> Obviously this is a good excuse to get better at both :)

I was hoping to find some time to provide an implementation based on it that
could be included in the standard library. It could be used to improve the
Symbol implementation for example. But time seems to be a scarce resource these
days, so it would be very nice if someone did it instead. ;)

Best,
Ismael

[Martin Odersky]

On Wed, May 20, 2009 at 5:36 AM, Paul Ford <pford@...> wrote:

>
>
> Martin Odersky wrote:
>>
>> I have finished a first implementation of 2.8 collections. ...
>>
>
> Gave the document a quick read. It seems to address and correct suprising
> semantics for the current collection operators. Behavior that I ran into,
> and was stumped by, within the first few hours of experimenting in earnest
> with Scala.
>
> The specific surprising behavior was inconsistent semantics of the ++
> operator depending on whether the the target was a mutable or immutable Set.
> I wrote a couple of precondition contracts on a pair of Set parameters
> asserting that they partitioned a third set. Much to my surprise and
> consternation "require(set1 ++ set2 == set3)" created an unexpected side
> effect on set1 when set1 was mutable, and no side effect at all (as intended
> and expected) when set1 was immutable.
>
> It appears in the 2.8 collections that operators with a collection result
> (such as +, ++, -, --) do not have side effects regardless of whether the
> target object is mutable or immutable. Side effects are explicit and
> intentional when the operator is of the form +=, ++=, +: etc.
>
> Is my understanding of the change in the 2.8 semantics correct?

Yes. --Martin

[Kieron.Wilkinson]

<mlists@...> wrote:
>Thankfully, if we use something similar to MapMaker we have the option of
either.

Yes, that was exactly what I was thinking. I wasn't intending to argue
that
this functionality be removed, but WeakHashMap does become rather
redundant
if we had something like MapMaker, so I wondered is this was a good time
to
provide one.

Do we also want to provide something akin to this for WeakHashSet also? I
see that is a new class in 2.8. I don't know the motivation for it, but I
can imagine why a soft-reference version might be useful (perhaps in this
case a SoftHashSet is more appropriate however).

> I was hoping to find some time to provide an implementation based on it
that
> could be included in the standard library. It could be used to improve
the
> Symbol implementation for example. But time seems to be a scarce
resource these
> days, so it would be very nice if someone did it instead. ;)

Indeed :)

It's probably asking what the scope is then. Do we want something similar
to
MapMaker, or do we just want something specific that can be used to make
maps
with weak/soft keys/values?

Or, perhaps something similar to MapMaker, the initial version of which
only
provides reference-map functionality, with a view to providing more stuff
later...

What are the requirements for Symbol, or does weak/soft keys/values cover
it?

Thanks,
Kieron

This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.

[Eric Willigers]

Kieron.Wilkinson@... wrote:
> Does the Option class fit into these new collections?

Option now has an implicit conversion to Iterable:-

implicit def option2Iterable[A](xo: Option[A]): Iterable[A] = xo.toList

So you can still call the various Iterable methods on an Option.







BTW, having overloads to support for the following:-

     buf += (x, y, z)
     xs + (x, y, z)
     xs - (x, y, z)
     xs += (x, y, z)
     xs -= (x, y, z)

contributes to the following odd behaviour:-

$ scala
Welcome to Scala version 2.8.0.r17751-b20090518021029


scala> val c = new scala.collection.mutable.ArrayBuffer[Product]()
c: scala.collection.mutable.ArrayBuffer[Product] = ArrayBuffer()

scala> val pa = ((1, 1), (2, 2))
pa: ((Int, Int), (Int, Int)) = ((1,1),(2,2))

scala> c += pa
res0: c.type = ArrayBuffer(((1,1),(2,2)))

scala> c += ((3, 3), (4, 4))
res1: c.type = ArrayBuffer(((1,1),(2,2)), (3,3), (4,4))

scala> val pb = (5, 6)
pb: (Int, Int) = (5,6)

scala> c += pb
res2: c.type = ArrayBuffer(((1,1),(2,2)), (3,3), (4,4), (5,6))

scala> c += (7, 8)
<console>:6: error: type mismatch;
  found   : Int(7)
  required: Product
        c += (7, 8)
              ^

scala>

[Ismael Juma]

<Kieron.Wilkinson <at> paretopartners.com> writes:
> Yes, that was exactly what I was thinking. I wasn't intending to argue
> that this functionality be removed, but WeakHashMap does become rather
> redundant if we had something like MapMaker, so I wondered is this was a
> good time to provide one.

Fair point.

> Do we also want to provide something akin to this for WeakHashSet also? I
> see that is a new class in 2.8. I don't know the motivation for it, but I
> can imagine why a soft-reference version might be useful (perhaps in this
> case a SoftHashSet is more appropriate however).

Not sure how often one need sets for that sort of thing to be honest.

> It's probably asking what the scope is then. Do we want something similar
> to MapMaker, or do we just want something specific that can be used to make
> maps with weak/soft keys/values?

My requirement is for a concurrent map that works with the various types of keys
and values. The computing map stuff is also useful, but that could perhaps be
done later.
 
> What are the requirements for Symbol, or does weak/soft keys/values cover
> it?

A Concurrent WeakHashMap is all it needs.

Best,
Ismael

[Marcus Downing]

Do tuples have a place in the new collections API?

[Martin Odersky]

Thanks for the corrections, Paul. I have applied them to my local copy.

 -- Martin


On Wed, May 20, 2009 at 5:02 AM, Paul Ford <pford@...> wrote:

>
>
> Martin Odersky wrote:
>>
>> I have finished a first implementation of 2.8 collections. ...
>>
>
> A few minor typos in "Scala 2.8 Collections", May 18, 2009:
>
> page 6, section 3.2, para 2: word "used" probably  missing from "less-often
> methods"
>
> page 6, figure 4: second "takeRight" should be "takeLeft"
>
> page 8, fig 6: "xs +: buf" should be "xs ++: buff"
>
> page 8, par 3 "inserAll" should be "insertAll"
>
> page 13, fig 10: missing closing paren in "ms += (k -> v"
>
> page 24, fig 18: "imscamutable" should be "immutable"
>
>
>
> --
> View this message in context: http://www.nabble.com/2.8-collections-tp23602869p23628197.html
> Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>

[Kieron.Wilkinson]

Ismael Juma <mlists@...> wrote on 20/05/2009 11:31:48:
> > It's probably asking what the scope is then. Do we want something
similar
> > to MapMaker, or do we just want something specific that can be used to
make
> > maps with weak/soft keys/values?
>
> My requirement is for a concurrent map that works with the various
> types of keys
> and values. The computing map stuff is also useful, but that could
perhaps be
> done later.

Okay, so eventually intending it to be a "full" MapMaker, rather than the
more specific "ReferenceMapMaker". I'm certainly not the person to write a
concurrent map (though I guess very few people are :), so I'm assuming I
can just embed a java.util.concurrent.ConcurrentHashMap instance behind a
Scala Map trait.

Anyway, thanks. I'll think about the best way of going about this.
Kieron


This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.