[External] : Re: Collection::getAny discussion

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 12 Mai 2021 03:03:33
> Objet: Re: [External] : Re: Collection::getAny discussion

> On 5/10/21 3:31 AM, Remi Forax wrote:
>> Thinking a little more about conflating "first" and "any".
>> I wonder if we have not already cross the Rubicon on that matter,
>> 
>> If we have a HashSet or any collections and using Stream.findFirst()
>>    var collection = new HashSet<>(...);
>>    var result = collection.stream().findFirst().orElseThrow();
>> 
>> We will get the result of collection.iterator().next()
>> 
>> So adding a default method getFirst() on Collection that returns the result of
>> iterator().next() is pretty coherent, no ?
> 
> Not really. Streams have a runtime notion of being ORDERED, and no static type.
> Adding Collection.getFirst() has no similar runtime notion.

The characteristics of a Spliterator/Stream reflects the properties of the collection from which the Spliterator was derived.

Anyway, the spec of Stream.findFirst() is not described in term of being ORDERED or not, it just says returns the first element of a Stream and a Stream can be created on any collections, ordered or not.
So having a method getFirst() on Collection returning the first element of the collection makes sense to me, the same way getting the first element of a Stream makes sense,
even if it implies getting a random element in case of a Set.

> This proposal is to add a static type for ordering/reversibility and corresponding operations for it.

Given that it's a proposal, i think it's fair to discuss other options if most of the intent of your proposal or the one from Tagir is kept.  

> 
> I'd still like to hear about the use cases for getAny or whatever we want to
> call
> the thing. Are callers interested in the collection having zero-or-one, exactly
> one,
> zero or more, or one or more elements? Talking about iterator().next() without
> considering the use cases, and their implications for pattern matching, is
> short-sighted.

Pattern matching (AFAIK) can not be used outside of a switch/instanceof, if as a user i'm required to wrap getFirst() inside a switch in order to get the first element, i will find that API cumbersome.

> 
> s'marks

Rémi