hrldcpr
Add intermediate purely immutable interfaces
Hi there, can you please provide a version in which your interfaces do not extend mutable Java interfaces?
Example:
Right now PVector<ELEMENT> extends List<ELEMENT>. This forces users to reference directly the underlying immutable types e.g., TreePVector<ELEMENT> to make sure that they are tryly immutable (an interface can be anything at runtime).
Proposed Solution
PVector<ELEMENT> would not implement List<ELEMENT> and offer only methods that read or create a new PVector from the existing one.
In order to work with the Collections API, it would expose a List<ELEMENT> toList() method.
I don't want to remove the interoperability with Java collections, but I agree it could be nice to have an intermediate "pure" immutable interface.
For example if the immutable methods were all in a new interface PersistentVector, then PVector would extend PersistentVector and List, and you can basically choose which level you want to pass around.
Maybe there could be an annotation we put on the mutable methods in each case such that an IDE would mark them as "not to be used"?
For example, if in PVector we re-declared the methods from the List interface and gave them a @Depreciated, maybe an IDE would recognize that if you had a PVector<T> v; that calling v.addAll(...) would be a no go.
I think we can all agree the trade-off between being a java.util.List<..> and not being a java.util.List<..> is a tricky one, but if it is bytecode compatible to just add IDE warnings that feels like a good start.
As a note, from a bit of research it seems this is what Guava did with their ImmutableList type
https://guava.dev/releases/23.0/api/docs/com/google/common/collect/ImmutableList.html https://github.com/google/guava/blob/master/guava/src/com/google/common/collect/ImmutableList.java
So that seems like relevant prior art.
Noticing the egg on my face due to what I suggested already being done.
https://github.com/hrldcpr/pcollections/blob/master/src/main/java/org/pcollections/PSequence.java
I'm gonna go ahead and close this, though of course anyone is welcome to create such a fork
Oh actually I forgot that there was an intermediate proposal as well, I'll reopen and retitle