ReversibleCollection proposal

[Stuart Marks]

> An API can not use ReversibleCollection as parameter before all the implementations of Collection that have an ordering are updated to implement ReversibleCollection instead of Collection.
> 
> By example, if I add a method
>    public void foo(ReversibleCollection c)
> in my library, people that want to be able to use foo with an existing collection with an ordering have to wait that collection implementation to be updated.
> 
> So i will not add a method like foo in my API until enough (whatever enough means) implementation of Collection with an ordering have migrated.
> 
> This is a similar issue as the migration from Python 2 to Python 3, it takes at least 10 years, so in 10 years, I will be able to had a public method that takes a ReversibleCollection in my API,
> without people not be able to using it.

This is a gigantic overstatement of the issue.

It is true that an API *in the JDK* as a practical matter cannot change a Collection 
parameter to ReversibleCollection, because it will break any callers that are 
currently passing Collection. The same is true of any library APIs where 
compatibility is a concern.

However, it can be quite useful in many contexts to use ReversibleCollection as a 
parameter. Newly introduced APIs can use ReversibleCollection. Certain APIs that 
consume List could reasonably be adjusted to consume a ReversibleCollection instead. 
(More likely an overload would probably be added in order to preserve binary 
compatibility.) In contexts where compatibility across maintenance boundaries is not 
an issue -- that is, where APIs can be changed incompatibly by updating all callers 
-- it's easy to imagine a variety of scenarios where a List or Collection parameter 
can usefully be adjusted to ReversibleCollection.

>> ReversibleCollection unifies a broad set of existing collections without
>> requiring
>> any retrofitting at all. Many applications and libraries don't have their own
>> collection implementations; they just use the ones in the JDK. They can benefit
>> from
>> the new APIs in ReversibleCollection immediately, without the need for any
>> retrofitting at all.
> 
> nope, many applications do not use *only* the collection from the JDK,
> but also collections that comes from other libraries than msut to be upgraded to use ReversibleCollection.

We're not actually disagreeing. Many applications and libraries *do* use only the 
collections in the JDK. It is probably also true that other collection libraries are 
popular and are *also* used in many places.

Non-JDK collections libraries benefit, because any List, SortedSet, and Deque 
implementations provided by these libraries are automatically retrofitted to 
implement ReversibleCollection.

> ReversibleCollection can be a solution, it's also not the best way to say that you want a collection with an ordering,
> any collections with zero or one element is also a valid ordered collection, so by example a HashSet with only one element is a valid argument.

Sure, this is vacuously true. It doesn't seem to be an argument against 
ReversibleCollection.

>> If we can ascertain (via code searching) that introducing covariant overrides to
>> LinkedHashMap introduces minimal incompatibilities, we might decide to go ahead
>> with
>> the change. (What's considered "minimal" is of course up for discussion.)
>>
>> If however we decide the incompatibilities are too great, a fallback plan would
>> be
>> to introduce new methods reversibleEntrySet() et al for the reversible views.
>> This
>> would be a little bit disappointing, but it doesn't invalidate the
>> ReversibleCollection/ReversibleSet concept.
> 
> It shows that the concept ReversibleCollection/ReversibleSet concept while useful out of the blue, needs to be shoehorned in the JDK, making it not worth it because the cost vs reward has changed.

Ah, now you're talking about cost vs. benefit. Thus, you must agree that 
ReversibleCollection/ReversibleSet is a valid concept!

It's premature to make a decision based on costs and benefits -- really, risks of 
incompatibilities. I've done some preliminary searching and what I've found so far 
is promising; the risk of incompatibilities seems low. Additional searching might 
reveal information that changes the situation.

s'marks