On 9/26/22 11:31 AM, Ernie Rael wrote:
maybe "interface ListIteratorProvider { ListIterator listIterator(int
index); }"
Doh! I guess that should be "interface ListIterable"
y 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
"setMaxS
llection usage involves too much external
iteration and too much check-then-act logic. Callers would have to
wrap those in synchronized blocks, and in general they don't know when
that's necessary. Certain transaction-style operations (like
Map::computeIfAbsent) can be made to work, but thos
(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 extends Collection" some months ago,
it has two implementations based on LinkedList and
cation, bi-directional might also be optional, to support
it's use with list equals.
-ernie
On 9/26/22 11:31 AM, Ernie Rael wrote:
A SequencedCollection listIterator() is missed; it's useful for
List.equals, or to implement a List in general. LinkedHashSet seems
incomplete without it. Even some
On 10/5/22 9:34 AM, Stuart Marks wrote:
On 10/4/22 9:38 PM, Ernie Rael wrote:
Summary of key points (maybe the mail was TL;DR)
OK thanks, I was still mulling over the previous email wondering which
parts were significant enough to reply to.
* SequencedCollection methods addFirst
And to make the noise worse, I posted from the wrong account.
On 22/12/05 9:09 AM, Ernie Rael wrote:
Apologies, accidentally hit send. Those links are notes. The
stackoverflow link is the best summary I've seen and references a bug
that can't be seen from the outside.
I'm hoping to find
This is about what might be a minor doc issue.
In https://openjdk.org/jeps/473 it says
As another example, |Stream::filter| takes a predicate that determines
whether an input element should be passed downstream; this is simply a
stateless one-to-many gatherer.
Shouldn't this be
n at initialization or finish, is it possible to have an
"empty" input?
-ernie
Cheers,
√
*
*
*Viktor Klang*
Software Architect, Java Platform Group
Oracle
----
*From:* core-libs-dev on behalf of
Ernie Rael
*
any-to-... At all, at no point it collapses a
subsequence of elements, it only works on one element at a time
On Sun, 7 Apr 2024, 19:31 Ernie Rael, wrote:
On 24/04/07 9:11 AM, Viktor Klang wrote:
Hi Ernie,
"Many" in this case refers to "N", which is "0 ... N
10 matches
Mail list logo
