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:54:18 GMT
Is the idea here to offer a wrapping API for such collections to
Groovy application developers, or merely use immutable collections
inside Groovy, without exposing them to application developers?

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

View raw message