On Tuesday, April 27, 2021 11:25 CEST, Peter Levart <peter.lev...@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
