-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add intermediate purely immutable interfaces #47
Comments
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 |
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 I think we can all agree the trade-off between being a |
As a note, from a bit of research it seems this is what Guava did with their https://guava.dev/releases/23.0/api/docs/com/google/common/collect/ImmutableList.html 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 |
Hi there, can you please provide a version in which your interfaces do not extend mutable Java interfaces?
Example:
Right now
PVector<ELEMENT>
extendsList<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 implementList<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.The text was updated successfully, but these errors were encountered: