On 4/28/21 2:04 AM, Stuart Marks wrote:
Binary compatibility is important. And I guess there is a variant of
the proposal that includes ReversibleCollection and ReversibleSet and
is binary compatible.
Yes, the source incompatibilities with the types seem to involve type
inference (e.g., use of var choosing differently based on new types in
the library) so it should be possible to make minor source code
changes to adjust or override the type that's inferred.
On binary compatibility, that comes mostly from the newly introduced
methods (reversed, addFirst etc.) and from adding covariant overrides
to LinkedHashSet. I guess the "variant" you mention is adding new
methods with the new return types (e.g., reversibleEntrySet) instead
of covariant overrides. Or was it something else?
Right, either adding new method with different name or not doing
anything (left to user to insert a cast). As you already pointed out,
introduction of NavigableSet/NavigableMap opted for new method name:
(navigableKeySet) and new method parameters (subMap, headMap, tailMap)
which were actually useful. So this trick might also bi applicable here:
public interface SortedMap/LinkedHashMap<K, V> {
ReversibleSet<Entry<K, V>> entrySet(boolean reversed);
ReversibleSet<K> keySet(boolean reversed);
ReversibleCollection<V> values(boolean reversed);
So you would say:
map.keySet(false) or map.keySet(true)
instead of:
map.reversibleKeySet() or map.reversibleKeySet().reversed()
The later is more readable, but nowadays almost everybody uses IDE(s),
so they see the following for the former:
map.keySet(reversed: false) or map.keySet(reversed: true)
Peter
Peter
