FCollection View vs unmodifiable vs Immutable Refactor

[Hanmac]

Currently the FCollection View sits in the FCollection Class and doesn't implement either java Collection or java List so each time we get a View and want to iterate over it in a different way, or want to get the size/empty check we need to cast to List or make a new Array List?

small steps:

• Make View implement List and Collection class, but make them fail on change, maybe implement them as Immutable List?
• Also use Immutable for EmptyFCollection ?
• Maybe add an Interface for FCollection that has all the methods (including the Modifying ones) and have View and Empty Collection use that Interface
• Implement FCollection as ForwardingList, + some Set Functions then it should be more easy to put a Immutable List inside for Empty?
• Or implement it as SetUniqueList / SetUniqueList

[github-actions[bot]]

This issue has not been updated in a while and has now been marked as stale. Stale messages will be auto closed.

[Hanmac]

My ideas so far to combine the points above:

• new FCollectionInterface that extends from Collection Interface
• new FCollectionAbstract that extends from ForwardingList/AbstractListDecorator, (so we could inject Immutable/Unmodifiable Views?)
• Then FCollection will extend FCollectionAbstract using SetUniqueList

hm, SetUniqueList would be a new Dependency to org.apache.commons.collections4 (more thinking)

That should be the best of all worlds 🤔

[Hanmac]

SetUniqueList isn't sortable

might need some trickery?

[Jetz72]

What does forwarding to a SetUniqueList add that our current FCollection implementation isn't already capable of?

[Hanmac]

What does forwarding to a SetUniqueList add that our current FCollection implementation isn't already capable of?

I wanted to try to reduce our own code for such collection to a community maintained one, to reduce the sources for possible errors

[Jetz72]

Would something like this work then?

• IFCollection - interface that implements Collection, possibly List, stream(), plus any other helper methods.
• FCollection - Implements IFCollection, extends SetUniqueList (rather than forwarding to it), and holds the list that the parent SetUniqueList operates on.
• FCollectionView - Implements IFCollection, wraps an FCollection, except all write methods throw unsupported operation exceptions.
• EmptyFCollection - Extends FCollectionView with an empty collection, all methods have trivial implementations.

Could possibly create distinct FCollectionView and UnmodifiableFCollection classes, where the latter has some extra logic built in to throw warnings if the underlying data set changes. But that'd just help with debugging.

[Hanmac]

@Jetz72 one of my reasons why i wanted other IFCollection implementations (or ones that extend from FCollectionAbstract) is to wrap Iterables.concat() or other stuff into something, so we could use FCollection filter/aggregate functions like min/max on them.

but that might not be needed anymore with Stream lib, right?

[Jetz72]

Creating collectors and accumulators based on the aggregate functions is one of my goals for that, yes. We can see how that pans out; it's close to the front of my to-do list once I have some time.

Streams do have Stream.concat(a, b). It won't filter out duplicates across the two input collections, though it wouldn't be too hard to write a utility method for doing that if we end up needing it.