Road to Beta

[qurbonzoda]

The primary focus of our current development is to promote the library from Alpha to Beta stability level. The implementation is already robust, with few bugs reported since its inception. However, some fundamental design choices need to be made before we finalize the library API design. Thus, we will focus on the following areas:

• Immutable vs. Persistent interfaces:
  • Decide whether to have both Immutable and Persistent sets of interfaces.
    • Rename from immutable to persistent #1
  • Provide implementations of Immutable collections that are not persistent.
    • immutable*Of(…) functions shouldn't be deprecated, and should return Immutable* instead of Persistent* #62
• Naming:
  • Determine if member functions of persistent collections that return a new instance should use a different naming scheme.
    • Naming for immutable collection modification operations #8
    • Rename removeAll/retainAll to filter/filterNot #139
  • Consider shorter names for persistent collections.
    • Giving Immutable Collections Shorter Names #14
  • Review the library’s public API, specifically extension function names.
    • Consider a different name for mutate  #65
• Providing static assurance of the underlying implementation:
  • Expose implementation classes.
    • Expose the implementation #66
  • Expose ordered types.
    • Expose Ordered types #106
    • Make ordered & non-ordered set/map implementations distinguishable #128
  • Prohibit custom implementations of Immutable and Persistent interfaces.
    • Make all immutable interfaces sealed to prevent implementations that allow mutations #147
• Feature parity with stdlib collections:
  • Resolve the issue of stdlib collection extensions for persistent collections.
    • Importing operators #10
    • Missing overloads of stdlib functions #12
    • Consider adding filterTo, mapTo, etc overloads #123
    • Map, Filter, etc. operations on an ImmutableList should return another ImmutableList #181

[Sporking]

The grouping of these that is used above seems a bit strange. It seems to me that issues #62, #66, #147, and #10 are basically the same issue, but they are grouped in different categories. In each of these, people are requesting true implementations of statically checkable immutable collections (ones which can't be subclassed to be non-immutable).

[rgoldberg]

Provide implementations of Immutable collections that are not persistent.
immutableOf(…) functions shouldn't be deprecated, and should return Immutable instead of Persistent* #62

#62 is not about Immutable* collections that aren't implemented as Persistent* collections. It's about keeping immutable*Of(…) functions, and their return type being Immutable*. If I need a collection that should never be modified, I do not want to expose functions that could be thought to mutate the collection. I know that the functions won't modify the underlying object, but I don't want to clutter the API of my immutable collection instance with those methods.

When the return type is Immutable*, that gives you the option to later create immutable objects that aren't actually persistent, in case you can optimize some performance or other characteristics.

The addition of a few simple static functions will take almost no maintenance effort, and barely adds to the complexity of the API. It provides more flexibility for future performance optimizations, and provides users a simple way to improve/tailor their usage of the library.

[kyay10]

One avenue to consider is that eventually multi field value classes will come to the language, and with them copying functions. If Persistent collections can expose copying functions, that'd allow for using them in a way that's near-identical to normal collections. However, that likely wouldn't work with the current design of having the methods named exactly the same as mutating methods.
In other words, I imagine a world where one can write:

var map: PersistentMap<K, V> = ...
map.put(k, v)

And get the correct result.
Just food for thought!
The counterargument to this is that one should use mutate anyways. In fact, a copying version of mutate is likely the the optimal design here!