- Mail original -
> De: "Stuart Marks"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> 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
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 = colle
- Mail original -
> De: "Stephen Colebourne"
> À: "core-libs-dev"
> Envoyé: Vendredi 30 Avril 2021 23:15:45
> Objet: Re: Collection::getAny discussion
> On Fri, 30 Apr 2021 at 19:50, Stuart Marks wrote:
>> You're asking for something t
To clarify, RichIterable is not a subclass of Collection. As we discovered in
JDK 15, a problem exists when we add default methods to interfaces that might
get “mixed” with other interfaces that already have those methods. There are a
few potential issues with adding zero argument default method
On Fri, 30 Apr 2021 at 19:50, Stuart Marks wrote:
> You're asking for something that's somewhat different, which you called the
> "find
> the first element when there is only one" problem. Here, there's a
> precondition that
> the collection have a single element. (It's not clear to me what shou
While I agree that we should be careful, let's not paint ourselves into
an either/or strawman. The choice is not "never add anything to
Collection" vs "let's dump every silly idea that comes to anyone's mind
into Collection"; it is, as always, going to involve tradeoffs between
stability and e
There is a default method getAny defined on the RichIterable interface in
Eclipse Collections. Adding a getAny with the same signature to Collection is
bound to cause a break similar to CharSequence.isEmpty did with JDK 15 but
possibly more extensive since RichIterable is the parent interface fo
