groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <>
Subject Re: peristant and immutable collections
Date Wed, 14 Oct 2015 09:59:28 GMT
Well... I think it's often preferable to use a library maintained by
someone else than by oneself, when the goal is to spend the time on
other things.

The pcollections project does not seem to have a lot of activity:

On Wed, Oct 14, 2015 at 11:55 AM, Guillaume Laforge <> wrote:
> PCollections sound like a good candidate, as you're its maintainer ;-) (so
> it's easy to fix bugs, make updates, etc), it's lightweight / standalone
> (not bringing odd dependencies).
> On Wed, Oct 14, 2015 at 10:55 AM, Jochen Theodorou <>
> wrote:
>> Hi all,
>> I was thinking of adding persistent collections to Groovy for quite a
>> while now. but I am wondering what library we should depend on here and
>> wanted to ask what you people generally use. Like pcollections, Guava,
>> functional Java, maybe stuff from Clojure or Scala?
>> Background:
>> persistent collection are collections (may or may not implement the
>> Collection interface) which cannot be modified later on. they have nothing
>> to do with persisting data in a database or on hard disc. They are just more
>> functional structures. Even though you cannot modify them, you can combine
>> the structure with new elements and get a new structure. So a list+element
>> will create a new list consisting of the old list and the new element. But
>> they will not just copy over data, they will reuse the internal structure of
>> the old list. A very simple form is that of a filo stack. It can be a simple
>> linked list of elements and we add the new element in front, letting us to
>> reuse the old list to almost 100% and to create only a very small amount of
>> new objects. There are of course lists, sets and maps.
>> So why use them? Unlike unmodifiable made collections in Java, these
>> persistent collections are relatively safe to share between threads with
>> minimal synchronizations. Also, if you are working with functional idioms
>> they are more fitting the implicit assumptions of the data not being
>> modifiable.
>> Java collections are in general a bad fit here, since Collections are more
>> or less assumed to be modifiable. pcollections for example tries to bridge
>> that. In a Java8 world there is of course streams, which are a much better
>> fit in that.
>> bye blackdrag
> --
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet
> Blog:
> Social: @glaforge / Google+

View raw message