Package one.microstream.collections.types

Interface XBag<E>

All Superinterfaces:
CapacityCarrying, CapacityExtendable, Clearable, ConsolidatableCollection, Consumer<E>, Copyable, ExtendedBag<E>, ExtendedCollection<E>, Iterable<E>, OptimizableCollection, Processable<E>, ReleasingCollection<E>, Sized, Truncateable, XAddGetCollection<E>, XAddingBag<E>, XAddingCollection<E>, XCollection<E>, XGettingBag<E>, XGettingCollection<E>, XIterable<E>, XJoinable<E>, XProcessingBag<E>, XProcessingCollection<E>, XPutGetBag<E>, XPutGetCollection<E>, XPuttingBag<E>, XPuttingCollection<E>, XRemovingBag<E>, XRemovingCollection<E>
All Known Subinterfaces:
XBasicList<E>, XLadder<E>, XList<E>
All Known Implementing Classes:
ArrayCollector, BulkList, EqBulkList, LimitList, LockedList, Single, SubList, SynchList
public interface XBag<E>
extends XPutGetBag<E>, XProcessingBag<E>, XCollection<E>
Bag type collections make the single demand (thus being a level 1 collection type) that duplicate elements have to be allowed, effectively being the opposite to set type collections.

The naming for the type is based on the conception that a bag can contain any elements (including duplicates), but is definitely not ordered.

Apologies to the Apache guys (but honestly: why should the conception of a "bag" imply that its contained elements are counted? Apart from that, counting elements is such a specific addon logic, that the proper approach would be to extend an existing type, like CountingList, etc. but surely not "bag", which implies unordered content).

This will probably be a rather academic type and has been introduced more for reasons of completeness of the typing architecture, as in practice, list type collections will be preferred to pure bag type collections.

Bag type collections are architectural on par with the other level 1 collection types set and sequence.

Currently, the only known to be useful subtype of a bag is the level 2 collection type list, combining bag and sequence (order of elements).

See Also:
XSet, XSequence, XList