[External] : Re: ReversibleCollection proposal

[Peter Levart]

On 4/28/21 7:19 AM, Stuart Marks wrote:
>
>
> On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
>> 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."
>
> Yes, to be clear, it was Stephen Coleborne who raised this previously 
> [1] and it's my response that's quoted above.
>
> Some further thoughts on this.
>
> This is an example where, depending on the current state of the 
> collection, the method might throw or it might succeed. This is useful 
> in concurrent collections (such as the capacity-restricted Deque 
> above), where the caller cannot check preconditions beforehand, 
> because they might be out of date by the time the operation is 
> attempted. In such cases the caller might not want to block, but 
> instead it might catch the exception and report an error to its caller 
> (or drop the request). Thus, calling the exception-throwing method is 
> appropriate.
>
> Something like SortedSet::addLast seems different, though. The state 
> is the *values* of the elements already in the collection. This is 
> something that can easily be checked, and probably should be checked 
> beforehand:
>
>     if (sortedSet.isEmpty() || sortedSet.last().compareTo(e) <= 0)
>         sortedSet.add(e);
>     else
>         // e wouldn't be the last element, do something different


I was thinking more of a case where the else branch would actually throw 
IllegalStateException and do nothing else - a kind of add with 
precondition check. A precondition in the sense of 
Objects.requireNonNull(). I can't currently think of a real usecase now, 
so this kind of operation is probably very rare. Probably not useful 
since if you're adding to SortedSet, the order of elements added should 
not matter because SortedSet will sort them. If you just want to check 
the order of elements added and you are not willing to pay the price of 
SortedSet, you will be adding them to a List or LinkedHashSet, but then 
the method would not do the check...


>
> Now this is a fair bit of code, and it would be shorter just to call 
> sortedSet.addLast(e). But does that actually help? What if e is 
> already in the set and is the last element?


In that case the operation would be a no-op (or it would replace the 
element with the parameter - a slight difference as the element can be 
.equals() but not the same instance).


> Is catching an exception really what we want to do if e wouldn't be 
> the last element? Maybe we'd want to do nothing instead. If so, 
> catching an exception in order to do nothing is extra work.


I was only thinking of situations where propagating the exception would 
be the desired thing.


>
> Again, I'd like to hear about use cases for a conditionally-throwing 
> version of addLast et. al. I don't want to be limited by failure of 
> imagination, but it does seem like this kind of behavior would be 
> useful only in a narrow set of cases where it happens to do exactly 
> the right thing. Otherwise, it just gets in the way, and its behavior 
> is pretty obscure. So, color me skeptical.


Right, I don't know how common such operation would be. Probably not very.


Peter

which are a continual source of errors.)

>
> I'll think about this more, but it doesn't seem promising.
>
> s'marks