ReversibleCollection proposal

[Peter Levart]

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