You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Jochen Theodorou <bl...@gmx.org> on 2015/10/14 10:55:08 UTC
peristant and immutable collections
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
Re: peristant and immutable collections
Posted by gerhard aschauer <g....@gmail.com>.
jochen,
- yes , I did and it works well (read performance) so far.
- No, its Scala roots did not impose any problems.
- Yes, that may pose a threat in the long run.
cheers,
gas
--
lg, /ga
On Wed, Oct 14, 2015 at 1:02 PM, Jochen Theodorou <bl...@gmx.org> wrote:
> On 14.10.2015 12:54, gerhard aschauer wrote:
>
>> hi,
>>
>> I'd recommend: https://github.com/arnohaase/a-foundation
>>
>
> why would you recommend it? Did you use it before and it works well?
> Doesn't the Scala heritage impose some problems for usage in the Java world
> only? And don't they currently reinvent their collections too?
>
> bye blackdrag
>
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 14.10.2015 12:54, gerhard aschauer wrote:
> hi,
>
> I'd recommend: https://github.com/arnohaase/a-foundation
why would you recommend it? Did you use it before and it works well?
Doesn't the Scala heritage impose some problems for usage in the Java
world only? And don't they currently reinvent their collections too?
bye blackdrag
Re: peristant and immutable collections
Posted by gerhard aschauer <g....@gmail.com>.
hi,
I'd recommend: https://github.com/arnohaase/a-foundation
cheer,
gas
--
lg, /ga
On Wed, Oct 14, 2015 at 12:53 PM, Jochen Theodorou <bl...@gmx.org>
wrote:
> On 14.10.2015 11:54, Thibault Kruse wrote:
>
>> 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?
>>
>
> I would like to use them internally as well as offering them to Groovy
> developers. The point being, that if I have them in groovy-core they bring
> some size to the jars as well, unless I use jarjar to pick out only the
> stuff I want to and put them in a separate namespache. but unless there is
> a good reason to do so, I would prefer having the library being generally
> available. If we just provide a wrapper it does not have to be part of
> groovy-core at all. And I am thinking that if we have a kind of standard
> library, we can take care of its classes in the runtime better and maybe
> gpars would use that as well in the long term for some things.
>
> bye blackdrag
>
>
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 14.10.2015 11:54, Thibault Kruse wrote:
> 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?
I would like to use them internally as well as offering them to Groovy
developers. The point being, that if I have them in groovy-core they
bring some size to the jars as well, unless I use jarjar to pick out
only the stuff I want to and put them in a separate namespache. but
unless there is a good reason to do so, I would prefer having the
library being generally available. If we just provide a wrapper it does
not have to be part of groovy-core at all. And I am thinking that if we
have a kind of standard library, we can take care of its classes in the
runtime better and maybe gpars would use that as well in the long term
for some things.
bye blackdrag
Re: peristant and immutable collections
Posted by Thibault Kruse <ti...@googlemail.com>.
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 <bl...@gmx.org> 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
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 15.10.2015 12:59, Cédric Champeau wrote:
>
>
> 2015-10-15 12:29 GMT+02:00 Dierk König <dierk.koenig@canoo.com
> <ma...@canoo.com>>:
>
> To clarify my point:
>
> We would copy the code over from pcollections.
>
>
> IANAL, but I think we have to be careful if we do this, because of IP.
It is an MIT-style license, so this is shouldn't really be a problem.
Re: peristant and immutable collections
Posted by Russel Winder <ru...@winder.org.uk>.
On Thu, 2015-10-15 at 15:05 +0200, Jochen Theodorou wrote:
> On 15.10.2015 13:09, Paul King wrote:
> > I think pcollections or functional-java (via functional-groovy?)
> > seem
> > like the easiest paths to go. We should also decide whether to
> > assist
> > with static type checking we need the n-ary variants for things
> > like
> > Tuple, Predicate, Function etc. At some point we either need to
> > adopt
> > such generic interfaces or follow the Java8 direction.
>
> I think we will have to follow the Java8 direction long term.
Functional Java is fun but it replaces much of the Java 8+ core. So it
is a strategy decision whether to stay close to Java or allow
divergences to gain features. This is a fundamentally different thing
to that we have done to date even when using dependencies.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 15.10.2015 13:09, Paul King wrote:
> I think pcollections or functional-java (via functional-groovy?) seem
> like the easiest paths to go. We should also decide whether to assist
> with static type checking we need the n-ary variants for things like
> Tuple, Predicate, Function etc. At some point we either need to adopt
> such generic interfaces or follow the Java8 direction.
I think we will have to follow the Java8 direction long term.
bye blackdrag
Re: peristant and immutable collections
Posted by Paul King <pa...@asert.com.au>.
I think pcollections or functional-java (via functional-groovy?) seem
like the easiest paths to go. We should also decide whether to assist
with static type checking we need the n-ary variants for things like
Tuple, Predicate, Function etc. At some point we either need to adopt
such generic interfaces or follow the Java8 direction.
On Thu, Oct 15, 2015 at 8:59 PM, Cédric Champeau
<ce...@gmail.com> wrote:
>
>
> 2015-10-15 12:29 GMT+02:00 Dierk König <di...@canoo.com>:
>>
>> To clarify my point:
>>
>> We would copy the code over from pcollections.
>
>
> IANAL, but I think we have to be careful if we do this, because of IP.
Re: peristant and immutable collections
Posted by Cédric Champeau <ce...@gmail.com>.
2015-10-15 12:29 GMT+02:00 Dierk König <di...@canoo.com>:
> To clarify my point:
>
> We would copy the code over from pcollections.
>
IANAL, but I think we have to be careful if we do this, because of IP.
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 15.10.2015 12:29, Dierk König wrote:
> To clarify my point:
>
> We would copy the code over from pcollections.
> The difference is that we do not _maintain_ it in a different project that we have a dependency upon.
> We maintain it as part of the core.
> Also: pcollections may have other users than Groovy. But Groovy core doesn't have to deal with that.
That's an option we can keep open. If we need things special for Groovy
we can go the extension method way. In most cases we do not need to
extend GroovyObject for example. But of course you are right, we should
not be afraid of doing this, if there are bigger advantages.
bye blackdrag
Re: peristant and immutable collections
Posted by Dierk König <di...@canoo.com>.
To clarify my point:
We would copy the code over from pcollections.
The difference is that we do not _maintain_ it in a different project that we have a dependency upon.
We maintain it as part of the core.
Also: pcollections may have other users than Groovy. But Groovy core doesn't have to deal with that.
cheers
Dierk
> Am 15.10.2015 um 12:22 schrieb Guillaume Laforge <gl...@gmail.com>:
>
> Writing our own persistent collections would be quite a bit of work, it's not very realistic.
>
> On Thu, Oct 15, 2015 at 9:18 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> On 14.10.2015 18:17, Dierk König wrote:
> I'm for making our own, Groovy-specific version of persistent data types.
> It could become a separate module or live in the core module.
>
> if we are going to use it in groovy-core, it would have to become part of groovy-core. Frankly, if I would write something from scratch for Groovy, it would probably end up to something similar to pcollections again. That is because you normally need some level of interoperability (or easy wrappers) for the collection stuff, since so much in Groovy does use it already and since so much of it has special treatment in the runtime.
>
> bye blackdrag
>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+
Re: peristant and immutable collections
Posted by Guillaume Laforge <gl...@gmail.com>.
Writing our own persistent collections would be quite a bit of work, it's
not very realistic.
On Thu, Oct 15, 2015 at 9:18 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> On 14.10.2015 18:17, Dierk König wrote:
>
>> I'm for making our own, Groovy-specific version of persistent data types.
>> It could become a separate module or live in the core module.
>>
>
> if we are going to use it in groovy-core, it would have to become part of
> groovy-core. Frankly, if I would write something from scratch for Groovy,
> it would probably end up to something similar to pcollections again. That
> is because you normally need some level of interoperability (or easy
> wrappers) for the collection stuff, since so much in Groovy does use it
> already and since so much of it has special treatment in the runtime.
>
> bye blackdrag
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 14.10.2015 18:17, Dierk König wrote:
> I'm for making our own, Groovy-specific version of persistent data types.
> It could become a separate module or live in the core module.
if we are going to use it in groovy-core, it would have to become part
of groovy-core. Frankly, if I would write something from scratch for
Groovy, it would probably end up to something similar to pcollections
again. That is because you normally need some level of interoperability
(or easy wrappers) for the collection stuff, since so much in Groovy
does use it already and since so much of it has special treatment in the
runtime.
bye blackdrag
Re: peristant and immutable collections
Posted by Dierk König <di...@canoo.com>.
I'm for making our own, Groovy-specific version of persistent data types.
It could become a separate module or live in the core module.
cheers
Dierk
Re: peristant and immutable collections
Posted by Alessio Stalla <al...@gmail.com>.
On Wed, Oct 14, 2015 at 5:54 PM, Winnebeck, Jason <
Jason.Winnebeck@windstream.com> wrote:
>
> What I don’t get about pcollections is that it promises to implement
> collections interfaces like Java.util.List, but then says that “add”
> doesn’t work, because you have to use plus. So, I’m not sure how it can
> really be a List when none of the mutators could work. I suppose you can
> implement size, iterator, contains, etc. same as Java’s unmodifiableList.
>
The Java Collections API specifies all mutator methods to be optional, i.e.
conforming implementations can throw UnsupportedOperationException.
Granted, it would have been better to have separate List and MutableList
interfaces, but that's how it is. All in all, the Java Collections API is
surprisingly good after all these years, in my opinion.
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 14.10.2015 20:35, Cédric Champeau wrote:
[...]
> Also strong -1 for any dependency on Scala, for almost the same reasons:
> strong history of breaking binary compatibility, all libraries of Scala
> have to be built against multiple versions of Scala. Plus it would
> dramatically increase the size of the distribution.
Afaik the suggested a-foundation classes do not depend on Scala at all.
Of course I would not suggest a dependency on Scala directly, some for
Clojure. Not because they are bad, but because you pull in too much
stuff. A-foundation and clj-ds try to get around the problem by having
no dependency on anything outside. But of course like typical with
Scala, A-foundation still brings a lot of classes.
bye blackdrag
Re: peristant and immutable collections
Posted by Cédric Champeau <ce...@gmail.com>.
I totally agree that we should not embed big jars. The Groovy distribution
must remain as small as possible. We made a great effort in reducing it in
the past releases, let's not kill that.
Also strong -1 for Guava, which is more a framework than a library: lots of
software use it and I've rarely seen a library that despite being very
helpful breaks so often binary compatibility, making it a nightmare to deal
with conflicts in transitive dependencies.
Also strong -1 for any dependency on Scala, for almost the same reasons:
strong history of breaking binary compatibility, all libraries of Scala
have to be built against multiple versions of Scala. Plus it would
dramatically increase the size of the distribution.
2015-10-14 17:54 GMT+02:00 Winnebeck, Jason <Ja...@windstream.com>
:
> Pcollections looks very promising. If this is scheduled to be a dependency
> for all groovy apps, I can’t imagine we could accept something like Guava,
> which is very large, without at least trimming it down. The pcollections
> tests don’t seem to be comprehensive, and developers normally expect a
> library like collections to be *spot* on even in very obscure edge cases.
> So I would have some concern about the popularity of pcollections vs.
> something like Guava. Lack of activity isn’t necessarily a bad indicator –
> this is the type of code you want to be absolutely perfect and never, ever,
> touch again. Think about the Java 7 Collections.sort/Comparator issue
> causing so many backward compatibility issues even though the new code was
> well within the specification.
>
>
>
> What I don’t get about pcollections is that it promises to implement
> collections interfaces like Java.util.List, but then says that “add”
> doesn’t work, because you have to use plus. So, I’m not sure how it can
> really be a List when none of the mutators could work. I suppose you can
> implement size, iterator, contains, etc. same as Java’s unmodifiableList.
>
>
>
> Jason
>
>
>
> *From:* Shil Sinha [mailto:shil.sinha@gmail.com]
> *Sent:* Wednesday, October 14, 2015 11:41 AM
> *To:* users@groovy.incubator.apache.org
> *Subject:* Re: peristant and immutable collections
>
>
>
> +1 for pcollections for the reasons Guillaume mentioned.
>
>
>
> Drawbacks of the other options:
>
>
>
> Guava - AFAIK only provides immutable collections
>
> Scala - As Jochen said, Collections (along with the standard library) will
> be redesigned in the near future -
> https://github.com/lampepfl/dotty/issues/818
>
> FunctionalJava - Data structures are only somewhat GDK friendly (they
> implement Iterable, but not Map, Set or List)
>
>
>
> Alessio, is https://github.com/krukow/clj-ds the Clojure data structures
> port you were thinking of?
>
>
>
>
>
>
>
> On Wed, Oct 14, 2015 at 8:02 AM, Cédric Champeau <
> cedric.champeau@gmail.com> wrote:
>
> +1 for pcollections. Lack of activity doesn't mean lack of maturity or
> lack of future activity.
>
>
>
> 2015-10-14 14:00 GMT+02:00 Guillaume Laforge <gl...@gmail.com>:
>
> Also, PCollections is pretty friendly to the good old Map, Set, List
> interfaces, which would be thus Groovy-friendly too, with all our GDK
> shortcuts for these classes.
>
>
>
> On Wed, Oct 14, 2015 at 12:56 PM, Jochen Theodorou <bl...@gmx.org>
> wrote:
>
> On 14.10.2015 11:55, 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).
>
>
> I can even make more fine grained jars and such, yes. But I don't want to
> impose a library to others for this. And while I am the maintainer, I did
> not really do much yet. There is quite some work to do for this library to
> be more up to date and to improve the benchmarks. I may spend that time
> anyway, just with a longer time period then
>
>
> bye blackdrag
>
>
>
>
>
> --
>
> Guillaume Laforge
> Apache Groovy committer & PMC member
>
> Product Ninja & Advocate at Restlet <http://restlet.com>
>
>
>
> Blog: http://glaforge.appspot.com/
>
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
>
>
> ------------------------------
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 14.10.2015 17:54, Winnebeck, Jason wrote:
[...]
> What I don’t get about pcollections is that it promises to implement
> collections interfaces like Java.util.List, but then says that “add”
> doesn’t work, because you have to use plus. So, I’m not sure how it can
> really be a List when none of the mutators could work. I suppose you can
> implement size, iterator, contains, etc. same as Java’s unmodifiableList.
yes, just as you say.
bye blackdrag
RE: peristant and immutable collections
Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
Pcollections looks very promising. If this is scheduled to be a dependency for all groovy apps, I can’t imagine we could accept something like Guava, which is very large, without at least trimming it down. The pcollections tests don’t seem to be comprehensive, and developers normally expect a library like collections to be spot on even in very obscure edge cases. So I would have some concern about the popularity of pcollections vs. something like Guava. Lack of activity isn’t necessarily a bad indicator – this is the type of code you want to be absolutely perfect and never, ever, touch again. Think about the Java 7 Collections.sort/Comparator issue causing so many backward compatibility issues even though the new code was well within the specification.
What I don’t get about pcollections is that it promises to implement collections interfaces like Java.util.List, but then says that “add” doesn’t work, because you have to use plus. So, I’m not sure how it can really be a List when none of the mutators could work. I suppose you can implement size, iterator, contains, etc. same as Java’s unmodifiableList.
Jason
From: Shil Sinha [mailto:shil.sinha@gmail.com]
Sent: Wednesday, October 14, 2015 11:41 AM
To: users@groovy.incubator.apache.org
Subject: Re: peristant and immutable collections
+1 for pcollections for the reasons Guillaume mentioned.
Drawbacks of the other options:
Guava - AFAIK only provides immutable collections
Scala - As Jochen said, Collections (along with the standard library) will be redesigned in the near future - https://github.com/lampepfl/dotty/issues/818
FunctionalJava - Data structures are only somewhat GDK friendly (they implement Iterable, but not Map, Set or List)
Alessio, is https://github.com/krukow/clj-ds the Clojure data structures port you were thinking of?
On Wed, Oct 14, 2015 at 8:02 AM, Cédric Champeau <ce...@gmail.com>> wrote:
+1 for pcollections. Lack of activity doesn't mean lack of maturity or lack of future activity.
2015-10-14 14:00 GMT+02:00 Guillaume Laforge <gl...@gmail.com>>:
Also, PCollections is pretty friendly to the good old Map, Set, List interfaces, which would be thus Groovy-friendly too, with all our GDK shortcuts for these classes.
On Wed, Oct 14, 2015 at 12:56 PM, Jochen Theodorou <bl...@gmx.org>> wrote:
On 14.10.2015 11:55, 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).
I can even make more fine grained jars and such, yes. But I don't want to impose a library to others for this. And while I am the maintainer, I did not really do much yet. There is quite some work to do for this library to be more up to date and to improve the benchmarks. I may spend that time anyway, just with a longer time period then
bye blackdrag
--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet<http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
Re: peristant and immutable collections
Posted by Shil Sinha <sh...@gmail.com>.
+1 for pcollections for the reasons Guillaume mentioned.
Drawbacks of the other options:
Guava - AFAIK only provides immutable collections
Scala - As Jochen said, Collections (along with the standard library) will
be redesigned in the near future -
https://github.com/lampepfl/dotty/issues/818
FunctionalJava - Data structures are only somewhat GDK friendly (they
implement Iterable, but not Map, Set or List)
Alessio, is https://github.com/krukow/clj-ds the Clojure data structures
port you were thinking of?
On Wed, Oct 14, 2015 at 8:02 AM, Cédric Champeau <ce...@gmail.com>
wrote:
> +1 for pcollections. Lack of activity doesn't mean lack of maturity or
> lack of future activity.
>
> 2015-10-14 14:00 GMT+02:00 Guillaume Laforge <gl...@gmail.com>:
>
>> Also, PCollections is pretty friendly to the good old Map, Set, List
>> interfaces, which would be thus Groovy-friendly too, with all our GDK
>> shortcuts for these classes.
>>
>> On Wed, Oct 14, 2015 at 12:56 PM, Jochen Theodorou <bl...@gmx.org>
>> wrote:
>>
>>> On 14.10.2015 11:55, 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).
>>>>
>>>
>>> I can even make more fine grained jars and such, yes. But I don't want
>>> to impose a library to others for this. And while I am the maintainer, I
>>> did not really do much yet. There is quite some work to do for this library
>>> to be more up to date and to improve the benchmarks. I may spend that time
>>> anyway, just with a longer time period then
>>>
>>>
>>> bye blackdrag
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC member
>> Product Ninja & Advocate at Restlet <http://restlet.com>
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
Re: peristant and immutable collections
Posted by Cédric Champeau <ce...@gmail.com>.
+1 for pcollections. Lack of activity doesn't mean lack of maturity or lack
of future activity.
2015-10-14 14:00 GMT+02:00 Guillaume Laforge <gl...@gmail.com>:
> Also, PCollections is pretty friendly to the good old Map, Set, List
> interfaces, which would be thus Groovy-friendly too, with all our GDK
> shortcuts for these classes.
>
> On Wed, Oct 14, 2015 at 12:56 PM, Jochen Theodorou <bl...@gmx.org>
> wrote:
>
>> On 14.10.2015 11:55, 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).
>>>
>>
>> I can even make more fine grained jars and such, yes. But I don't want to
>> impose a library to others for this. And while I am the maintainer, I did
>> not really do much yet. There is quite some work to do for this library to
>> be more up to date and to improve the benchmarks. I may spend that time
>> anyway, just with a longer time period then
>>
>>
>> bye blackdrag
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet <http://restlet.com>
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: peristant and immutable collections
Posted by Guillaume Laforge <gl...@gmail.com>.
Also, PCollections is pretty friendly to the good old Map, Set, List
interfaces, which would be thus Groovy-friendly too, with all our GDK
shortcuts for these classes.
On Wed, Oct 14, 2015 at 12:56 PM, Jochen Theodorou <bl...@gmx.org>
wrote:
> On 14.10.2015 11:55, 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).
>>
>
> I can even make more fine grained jars and such, yes. But I don't want to
> impose a library to others for this. And while I am the maintainer, I did
> not really do much yet. There is quite some work to do for this library to
> be more up to date and to improve the benchmarks. I may spend that time
> anyway, just with a longer time period then
>
>
> bye blackdrag
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: peristant and immutable collections
Posted by Jochen Theodorou <bl...@gmx.org>.
On 14.10.2015 11:55, 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).
I can even make more fine grained jars and such, yes. But I don't want
to impose a library to others for this. And while I am the maintainer, I
did not really do much yet. There is quite some work to do for this
library to be more up to date and to improve the benchmarks. I may spend
that time anyway, just with a longer time period then
bye blackdrag
Re: peristant and immutable collections
Posted by Jacques Le Roux <ja...@les7arts.com>.
That sounds like a good advice, though Google can be surprising sometimes...
Jacques
Le 14/10/2015 11:59, Thibault Kruse a écrit :
> 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:
> https://www.openhub.net/p/pcollections
>
> On Wed, Oct 14, 2015 at 11:55 AM, Guillaume Laforge <gl...@gmail.com> 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 <bl...@gmx.org>
>> 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: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
Re: peristant and immutable collections
Posted by Thibault Kruse <ti...@googlemail.com>.
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:
https://www.openhub.net/p/pcollections
On Wed, Oct 14, 2015 at 11:55 AM, Guillaume Laforge <gl...@gmail.com> 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 <bl...@gmx.org>
> 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: http://glaforge.appspot.com/
> Social: @glaforge / Google+
Re: peristant and immutable collections
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <bl...@gmx.org>
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 <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: peristant and immutable collections
Posted by Alessio Stalla <al...@gmail.com>.
IIRC there used to be a clojure-data-structures project of some sort, which
ported Clojure collections to pure Java (i.e. not requiring Clojure's
runtime). I don't know if it still exists, but it might be worth looking.
On Wed, Oct 14, 2015 at 10:55 AM, Jochen Theodorou <bl...@gmx.org>
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
>