-
ListView
- an ordered list -
SetView
- a set -
MapView
- an associative array -
BagView
- a multiset -
MutableCollection
get
- gets the next element that would be returned by a call toremove()
add
- adds an element to the collectionList
- adds at the backStack
- adds to the frontQueue
- adds to the backPriorityQueue
- adds somewhereSet
- adds anywhere
remove
- removes an element from the collection (from the back of a list)List
- removes from the backStack
- removes from the frontQueue
- removes from the frontSet
- removes anything
- NOTE: there is no guarantee that
add(e)
remove()
returns the same elemente
.
-
MutableList
:MutableCollection
peek
- gets the next element that would be returned by a call topop()
push
- adds an element at the front of the listpop
- removes an element at the front of the list
For a stack, use push
and pop
.
For a queue, use add
and pop
, or push
and remove
.
Here is a proposal for a ListView
interface implementation:
High-level design goals:
- Performant: where possible, allocations are reduced or removed (e.g.,
Iterator
allocations), and where possible, the code will exit early (e.g., a size test before comparing lists) - It should be easy to implement
ListView
orCollectionView
; therefore there are many useful default implementations in the interface - Code should not have to access the actual implementations: all classes are package local, only
ListView<E>
andCollectionView<E>
are externally visible - Similarly, all interfaces provide
of()
,from()
andfromCopy()
static functions that can create new instances of the corresponding interface. The implementation is free to choose the actual implementation, and whether to return a new instance or an existing one.
Details:
- The methods
of()
,from()
andfromCopy()
create new instances from an array of elements, a list, or a copy of a list respectively. The distinction between from() and of() is allow the creation of a list of lists. - The methods
of()
,from()
andfromCopy()
are statically defined on the interfacesListView
andCollectionView
. This way, you can explicitly specify whether you want aListView
(usingListView.of()
) or aCollectionView
(usingCollectionView.of()
). IfListView
andCollectionView
where classes, thenListView.of()
could not overrideCollectionView.of()
and return a different type. - Depending on the overload called, the
ListView
orCollectionView
creates a different implementation. - There is one implementation for empty lists, whose methods can quickly return that the list is empty. There is one instance of the empty list, which is returned for all empty lists.
- There is one implementation for singleton lists, whose methods are optimized for this use case.
- There is one implementation wrapping a list (and one wrapping a collection), delegating all operations to the underlying list or collection.
- There is one implementation wrapping an array. Without this, a
ListView
would wrap a list that wraps an array, and all delegating methods would have another layer of indirection. - Lists return the same hashcode as the
AbstractList
of Java. - Lists can be compared to any
Iterable
. - The default implementations return themselves on a call to
asUnmodifiable()
, making this very cheap.
The mutable collection interfaces implement the normal Java interfaces as well, and actually guarantee that they can be mutated (therefore adhering to the interface specification).
The immutable collection interfaces guarantee that the collection never changes and that it's
thread-safe. The persistent collection interfaces allow the collection to be changed,
where each change returns a new persistent collection. They also provide a builder()
method,
which returns a Builder
object that implements the corresponding mutable collection interface.