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
