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
Stephen
