Skip to content

Conversation

@kfriedberger
Copy link
Member

… to directly show the immutability.

This might optimise internal operations, e.g.,
avoid copies from List to other Lists, if all are ImmutableLists.

…copyOf" to directly show the immutability.

 This might optimise internal operations, e.g.,
 avoid copies from List to other Lists, if all are ImmutableLists.
…directly show the immutability.

This might cause one additional copy of the array-content in some cases,
however, we iterate over the content again in the next step,
so this is just a very small overhead,
and it brings the benefit of immutability.
@baierd
Copy link
Contributor

baierd commented Sep 3, 2025

Good idea!

Question: do we also want to switch to ImmutableList etc. for internal API declarations?
E.g. protected abstract TFormulaInfo distinctImpl(ImmutableList<TFormulaInfo> pNumbers);.

@baierd baierd added this to the Release 6.0.0 milestone Sep 3, 2025
@kfriedberger
Copy link
Member Author

For the internal method signature, the benefit is quite small. Keeping signatures with List seems less strict for implementations, and avoids potential copies if a method already gets a list from calling code.

@kfriedberger kfriedberger merged commit 71fcd6a into master Sep 3, 2025
3 checks passed
@kfriedberger kfriedberger deleted the feat/immutable-lists branch September 3, 2025 19:28
@PhilippWendler
Copy link
Member

This PR has the same problem as I mentioned in d344e3a#commitcomment-165053827: It adds additional unnecessary copies by replacing Arrays.asList with a copy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants