Re: ReversibleCollection proposal

[Anthony Vanelverdinghe]

On Tuesday, April 27, 2021 11:25 CEST, Peter Levart <peter.levart at gmail.com> wrote:  
> Now just some of my thoughts about the proposal:
> 
> - SortedSet.addFirst/.addLast - I think an operation that would be used 
> in situations like: "I know this element should always be greater than 
> any existing element in the set and I will push it to the end which 
> should also verify my assumption" is a perfectly valid operation. So 
> those methods throwing IllegalStateException in case the invariant can't 
> be kept seem perfectly fine to me.

This was raised before and addressed by Stuart in [0]:
"An alternative as you suggest might be that SortedSet::addFirst/addLast could throw 
something like IllegalStateException if the element is wrongly positioned. 
(Deque::addFirst/addLast will throw ISE if the addition would exceed a capacity 
restriction.) This seems error-prone, though, and it's easier to understand and 
specify that these methods simply throw UOE unconditionally. If there's a good use 
case for the alternative I'd be interested in hearing it though."

> - ReversibleCollection.addFirst/.addLast are specified to have void 
> return type. This works for List and Deque which always add element and 
> so have no information to return. OTOH Collection.add is specified to 
> return boolean to indicate whether collection was modified or not, but 
> Set modifies the specification of that method a bit to be: return false 
> or true when Set already contained an element equal to the parameter or 
> not. So ReversibleCollection.addFirst/.addLast could play the same 
> trick. for List(s) and Deque(s) it would always return true, but for 
> ReversibleSet(s) it would return true only if the set didn't contain an 
> element equal to the parameter, so re-positioning of equal element would 
> return false although the collection was modified as a result.

If addFirst/addLast were to return boolean, Deque would no longer compile due to its existing methods being incompatible with the new ones.

> Regards, Peter

Kind regards, Anthony

[0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076518.html