----- Mail original -----
> De: "Stephen Colebourne" <scolebou...@joda.org>
> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>
> Envoyé: Jeudi 22 Avril 2021 00:14:10
> Objet: Re: ReversibleCollection proposal
> On Wed, 21 Apr 2021 at 18:39, Stuart Marks <stuart.ma...@oracle.com> wrote:
>> The value being provided here is that the ReversibleCollection interface
>> provides a
>> context within which specs no longer need to hedge about "if the collection
>> has
>> an
>> ordering". APIs that produce or consume ReversibleCollection no longer need
>> to
>> include this hedge, or have disclaimers about ordering. Potential new
>> ReversibleCollection implementations also need not worry about this issue in
>> the
>> same way they did when they were forced to implement Collection directly.
>
> Having thought about this for a few days my "interesting thought" is
> that adding a `ReversibleCollection` interface and adding additional
> methods can be orthogonal choices.
>
> Specifically, I do rather like Peter's suggestion of adding more
> methods to Collection. Adding these methods would be pretty useful in
> general and give the proposed change much greater reach:
>
> public interface Collection<E> .... {
> default void addFirst(E e) { throw new
> UnsupportedOperationException(); }
> default E getFirst() { return iterator().next(); }
> default E removeFirst() { var i = iterator(); i.next();
> i.remove(); }
> }
>
> My view being that every collection has some notion of "first", even
> if that notion is "undefined". If that was the only change made, I
> think that would be a good move forward.
>
> These would be the various options:
>
> - 7 new methods on ReversibleCollection (Stuart's suggestion)
> - 7 new methods on Collection, no ReversibleCollection (Peter's suggestion)
> - 3 new methods on Collection, no ReversibleCollection (my suggestion #1)
> - 3 new methods on Collection, 4 methods on ReversibleCollection (my
> suggestion #2)
> - 7 new methods on Collection, 0 methods on ReversibleCollection (my
> suggestion #3)
>
> FWIW, I think I prefer my suggestion #2
I would like to preserve the invariant that, when calling a method on a
Collection/iterator, an UnsupportedOperationException only occurs when trying
to mutate that collection.
If we are ok with that, this means that addFirst can not be a default method of
Collection.
getFirst() on Collection is a nice addition has I already said.
And i'm not a big fan of removeFirst() on Collection, mostly because i think
that the sequence this.iterator + next() + remove() is pretty rare on a
Collection or a Set
(i would also like to keep the invariant that Set and Collection have the same
set of methods).
So addFirst/addLast/removeFirst/removeLast should be added to
SortedSet/NavigableSet, Deque, List and LinkedHashMap (if there are not already
present).
For reverse/descending, I still prefer to have descendingSet() on Set and
descendingList() on List, the same way we have keySet() or subList() (the
method names have the resulting interface has suffix).
This also solve the issue with LinkedList implementing both List and Deque.
I believe that the cost of introducing ReversibleCollection is too high
- it's not source backward compatible change
- replacing Collection/Set by ReversibleCollection/ReversibleSet has return
type of an existing interface/class is not a source backward compatible change
- to be able to use ReversibleCollection parameter of a public method of a
library, we have to wait the whole Java ecosystem to have been updated to
implement ReversibleCollection (Python 2/3 like migration).
>
> Stephen
Rémi
