On 5/1/21 7:36 AM, Peter Levart wrote:
On 4/30/21 9:25 PM, Stuart Marks wrote:
So I think we're stuck with void-returning add{First,Last} methods.
Have you thought of perhaps not adding them at all?
Collection.add() for:
List(s) - behaves the same as addLast()
LinkedHashSet - behaves the same as addLast()
Deque - behaves the same as addLast()
So for all ReversibleCollection(s) where it works, addLast() would be equivalent to
add()
addFirst(x) can be written as: reversed().add(x) if reversed() is specified to
return a reversed view over the underlying ReversibleCollection.
To me, and I think to most people, add, get, and remove all belong together, just
like offer/peek/poll. (See the tables in the Deque class spec.) Of course the issue
is that addX can't be implemented for SortedSet (or it can be, but only with some
contrivances discussed previously). The choice is between which asymmetry we want:
1. add/get/remove across most of the ReversibleCollection implementations except for
SortedSet, or
2. get/remove across all ReversibleCollection implementations, with addX() "missing"
from the set of operations.
As you point out, add() is kind of like addLast(), except without the reordering
semantics for LinkedHashSet. And reversed().add() is a roundabout way of saying
addFirst() -- also without the reordering semantics for LinkedHashSet. I think most
people's reactions would be "Why didn't they just provide addFirst/addLast?" Plus
the reordering would be missing for LHS.
A second-order issue is performance. I'd expect that implementations would want to
provide a fast-path for addFirst() that is amenable to JIT optimization; this seems
harder to achieve with reversed().add().
s'marks
