RFC: draft API for JEP 269 Convenience Collection Factories (original) (raw)
Stephen Colebourne scolebourne at joda.org
Fri Oct 9 13:11:47 UTC 2015
- Previous message: RFC: draft API for JEP 269 Convenience Collection Factories
- Next message: RFC: draft API for JEP 269 Convenience Collection Factories
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote:
1. Number of fixed arg overloads.
Guava follows this pattern:
of(T) of(T, T) of(T, T, T) of(T, T, T, T... elements)
whereas the proposal has
of(T) of(T, T) of(T, T, T) of(T... elements)
I'd be interested to know why Guava did it that way and what the trade offs are.
2. Other concrete collection factories.
I've chosen to provide factories for the concrete collections ArrayList, HashSet, and HashMap, since those seem to be the most commonly used. Is there a need to provide factories for other concrete collections, such as LinkedHashMap?
LinkedHashMap definitely LinkedList definitely not (as its very slow and use should not be encouraged). TreeSet/TreeMap, maybe, they'd need an extra parameter though.
3. Duplicate handling.
My current thinking is for the Set and Map factories to throw IllegalArgumentException if a duplicate element or key is detected.
Definitely.
Given that ofEntries() takes a Map.Entry as input, why does Map.KeyValueHolder need to be public? This would require Map.entry(K,V) return Map.Entry, not Map.KeyValueHolder.
Stephen
- Previous message: RFC: draft API for JEP 269 Convenience Collection Factories
- Next message: RFC: draft API for JEP 269 Convenience Collection Factories
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]