[External] : Re: ReversibleCollection proposal

[Stuart Marks]

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