> I don't see why you think a general collection...
I thought the Subject would be sufficient to indicate that I was not
talking about collections in general. I should have been more precise
with my words; guess I was just excited by a bi-directional ordered set.
The MRU _example_ is useful; the current collections handle it poorly
and Sequenced Collections is ideal. Caches with an eviction policy are
common; I suspect caches will be a common use for SequencedSet family.
Note there are fixed sized Collections and SequencedCollection borrows
heavily from that family. Perhaps this issue should be considered in the
context of adding an **Eviction Policy** to appropriate collections.
MRU is a Collection; for example, I pass an MRU to a persistence
mechanism that takes a collection. Saying "all methods offered by
`Collection` should [not] even be part of an `MRU` interface" is
innacurate, especially when considered in the context of a
SequencedCollection.
-ernie
PS - Loosely related is extending a Collection and providing a
synchronized version. Is there a discussion about making the
SynchronizedCollection family of classes public?
On 9/21/22 4:22 AM, John Hendrikx wrote:
I don't see why you think a general collection, that is in 99.9% of
the cases not used to implement an MRU, should burden every call to
#add with a check to see if it isn't exceeding its maximum size or to
see if a maximum size has been set.
This is much better done by composition, as I don't think all methods
offered by `Collection` should even be part of an `MRU` interface.
--John
On 20/09/2022 21:08, Ernie Rael wrote:
(There may be a better place to send this, let me know where)
Suggesting an option to limit the size of the collection, e.g
"setMaxSize(int)", default of zero means no limit.
I put together "interface MRU<E> extends Collection<E>" some months
ago, it has two implementations based on LinkedList and
LinkedHashSet. The code can be seen at
https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/
A SequencedCollection, as outlined in the JEP draft 2020/09/01, would
be almost perfect to implement MRU; I've run into most of the
problems/issues discussed in the JEP draft.
The MRU is a cache, as I use it; it typically has a max size for the
collection. Handling this natively in the collection would be ideal;
if an add operation would overflow, remove the item at the other end.
Note that addAll() is used when initializing from backing store.
FYI, I use a "Supplier<Integer>" to the constructor to provide
maxSize, but a property makes much more sense. I'll make that change
in MRU for sanity, and get rid of the trim() method. setMaxSize can
do the trim.
-ernie
