1

I understand persistent in this context to mean preserving previous versions of a collection upon an attempt to modify it:

List<Integer> l = List.of(1, 2, 3);
List<Integer> l2 = l.append(4);

However, if I lose the reference l to the original collection I can't see any methods on the l2 that allow me to access the original collection? With persistent collections I would have expected:

l2.getPreviousVersion()

Maybe I am missing the point?

Andy Cribbens
  • 1,370
  • 2
  • 11
  • 22
  • 2
    The expectation is wrong. ["*A persistent data structure does preserve the previous version of itself when being modified and is therefore effectively immutable. Fully persistent data structures allow both updates and queries on any version.*"](https://docs.vavr.io/#_persistent_data_structures) – Turing85 Dec 26 '20 at 17:30
  • "immutable" and "mutable" sound too similar, so a new buzzword was needed: "persistent". – Johannes Kuhn Dec 26 '20 at 17:30

2 Answers2

0

All vavr collections are persistent. There are no API methods that would make it possible to mutate a vavr collection. That means, once you hold a reference to a vavr collection, you can be sure that it would not be changed by any part of the code(1).

What you're missing in the API would actually be a problem rather than a feature. If you could query the API for all previous versions of a collection that would mean that you're keeping all previous versions in memory. That would be a huge waste of resources and it would make the collections much less useful than they are. Currently, if you don't hold references to previous versions of a collection, the garbage collector is allowed to release memory that is used by the old versions.

If you want some sort of history of the evolution of a collection, you have to have the code responsible for keeping and evicting references to those collections. That way you would have full control over the memory use of your program.


(1) except hacks using reflection or similar tools that allows you to modify fields/memory directly, bypassing encapsulation

Nándor Előd Fekete
  • 6,988
  • 1
  • 22
  • 47
  • 1
    I thought that was what was meant by persistent (that a history is preserved) as opposed to immutable (which means nothing can change) – Andy Cribbens Dec 26 '20 at 19:18
  • 1
    @AndyCribbens persistent collections are more than just immutable collections, it implies more efficient storage than duplicating the references to the elements as simple immutable collections do. Persistent collections employ structural sharing which usually means only O(1) or O(log n) memory and run time cost–depending on the operation and the actual collection type–, instead of the usual O(n) memory and run time cost in case of simple immutable collections. Please read the [corresponding chapter](https://docs.vavr.io/#_data_structures_in_a_nutshell) in vavr's documentation for more details. – Nándor Előd Fekete Dec 26 '20 at 20:36
  • in that doc it mentions: "Fully persistent data structures allow both updates and queries on any version." So this means that VAVR collections are persistent but not 'fully persistent'? – Andy Cribbens Dec 26 '20 at 21:04
  • 1
    I don't know what the author meant with that sentence, but if I had to guess, he's talking about the type of collections that have real mutator methods that mutate internal state but still provide a mechanism to view different versions of the collection. To be honest I don't know of any real-world implementation of this kind of persistent collections. With vavr you can't mutate existing collections. You can only create new collections (possibly) based on existing collections with an additional update. The new collections will try to share as much storage with the original version as possible. – Nándor Előd Fekete Dec 26 '20 at 22:24
  • If you wanted such a collection you could easily implement it on top of vavr. You could have immutable persistent collection values internally, and a mutable Java Collection API facade in front of them for the updates. You add the methods for querying versions on top of the mutable Java Collection API to be able to query versions. It's definitely possible, but I would surely prefer working with just immutable values instead. – Nándor Előd Fekete Dec 26 '20 at 22:31
  • I think when they mention 'updates and queries' they mean the ability to create a new collection rather than actually 'update' it. – Andy Cribbens Dec 27 '20 at 10:24
  • Nandor, dased on yours and @Turing85 comments I think I understand that these are 'persistent' data structures and not 'Fully persistent' data structures. – Andy Cribbens Dec 27 '20 at 10:30
0

Preserving of the previous versions is not a directly intentional feature.

It is an consequence of immutability. As Turing85 said, accessing the previous versions is a feature of Fully Persistent data structures.

Sidias-Korrado
  • 383
  • 3
  • 12