[External] : Re: ReversibleCollection proposal

[Stuart Marks]

The line of discussion here was introduced by Remi, who was making an argument of 
the form "introducing a type cannot solve this particular problem, therefore, 
introducing a new type is not useful at all." I was providing an example of where 
the new type is useful as a method parameter. That's all.

> Have you considered the alternative of a collection providing a Reversed view of itself, in the same sense that unmodifiable collections are views of an underlying collection?

The proposal does define ReversibleCollection::reversed as providing a reversed 
view, through which modifications to the underlying collection are visible, and to 
which modifications are written through to the underlying collection. Or are you 
talking about something different?

s'marks

On 4/30/21 4:15 PM, Alan Snyder wrote:
> It sounds like the items processing maintainer would be looking for OrderedCollection and might or might not find ReversibleCollection. :-)
> 
> I suspect you would agree that OrderedCollection by itself is too weak to justify being a type. It’s basically Iterable with the extra bit that the iteration order is not an implementation artifact.
> 
> In this example, using the type system to detect a bug like the old bug seems like overkill. Even if the parameter were Ordered, it still might not be the *right* order. The maintainer of the client code needs to understand that.
> 
> Suppose the items processor wants to require that the parameter collection not contain duplicates. Would you suggest adding a type for that? Clearly Set would be just as unnecessarily restrictive as List was for ordering. Absurdity approaches…
> 
> The issue of Reversible remains, above and beyond Ordered. Have you considered the alternative of a collection providing a Reversed view of itself, in the same sense that unmodifiable collections are views of an underlying collection?
> 
>    Alan
> 
> 
> 
>> On Apr 30, 2021, at 3:42 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Consider the case of a large application or other system, one that's large enough to have lots of internal APIs, but that is built as a single unit, so release-to-release compatibility isn't an issue. Suppose there is some method
>>
>>     processItemsInOrder(List<Item> items)
>>
>> that has to process items in the order in which they occur, because processing of later items might depend the processing of earlier ones. The maintainer of this API chose to accept a List as a parameter, because it's a common interface and it's clearly an ordered collection.
>>
>> Now consider a client that gets items from different places, keeping them in order, but removing duplicates. It might do something like this:
>>
>>     var items = new LinkedHashSet<Item>();
>>     items.addAll(getItemsFromSomeplace());
>>     items.addAll(getItemsFromAnotherPlace());
>>     items.addAll(getItemsFromSomeplaceElse());
>>     processItemsInOrder(new ArrayList<>(items));
>>
>> It turns out the copying of the items into an ArrayList is a performance bottleneck, so the maintainer of the client code asks the maintainer of the items processing code to change the API to accept Collection instead.
>>
>> The items processing maintainer demurs, recalling that the API *did* accept Collection in the past, and a bug where somebody accidentally passed a HashSet resulted in a customer escalation because of item processing irregularities. In the aftermath of that escalation, the API was changed to List. The client maintainer reluctantly pursues alternatives for generating a deduplicated List.
>>
>> But wait! Those Java guys added a ReversibleCollection interface in Java N. It has the desired property of being ordered, and conveniently it's a supertype of both List and LinkedHashSet. The items processing maintainer adjusts the API to consume ReversibleCollection, and the client maintainer removes the temporary ArrayList, and everybody is happy.
>>
>> s'marks
>>
>