Skip to content
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

Open
msollecito-import opened this issue Mar 13, 2017 · 6 comments
Open

Add intermediate purely immutable interfaces #47

msollecito-import opened this issue Mar 13, 2017 · 6 comments

Comments

@msollecito-import
Copy link

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.

@hrldcpr
Copy link
Owner

hrldcpr commented Mar 22, 2018

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.

@bowbahdoe
Copy link

bowbahdoe commented Sep 19, 2020

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.

@bowbahdoe
Copy link

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.

@bowbahdoe
Copy link

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

@hrldcpr
Copy link
Owner

hrldcpr commented Sep 20, 2020

I'm gonna go ahead and close this, though of course anyone is welcome to create such a fork

@hrldcpr hrldcpr closed this as completed Sep 20, 2020
@hrldcpr
Copy link
Owner

hrldcpr commented Sep 20, 2020

Oh actually I forgot that there was an intermediate proposal as well, I'll reopen and retitle

@hrldcpr hrldcpr reopened this Sep 20, 2020
@hrldcpr hrldcpr changed the title Fork without implementing mutable interfaces. Add intermediate purely functional interfaces Sep 20, 2020
@hrldcpr hrldcpr changed the title Add intermediate purely functional interfaces Add intermediate purely immutable interfaces Sep 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants