- Mail original -
> De: "Brian Goetz"
> À: "Michael Kuhlmann" , "core-libs-dev"
>
> Envoyé: Mardi 17 Novembre 2020 20:44:17
> Objet: Re: 'Find' method for Iterable
> On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
>> But a
On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
But after thinking about it, I'm now convinced that it would be a bad
idea. Because it extends the scope of this small, tiny Iterable
interface to something bigger which it shouldn't be.
This response captures the essence of the problem. You m
I think that the discussion is still at the level of if it's an acceptable
addition and not yet at where to implement it. I gave my reasoning in
response to Stuart's points as to what I think is acceptable and what
isn't. Whether the java.lang package has special status is a bit ahead of
where we a
Hello all,
Were those downsides seriously considered and strongly argued against? :
(1) Iterable belongs to java.lang so, at least from how it is usually
approached, it's a feature at the very level of the language, not a
util feature like Collection. Adding a find on it, is it really
relevant, o
Did this discussion get lost?
On Sun, Sep 20, 2020 at 1:27 AM Nir Lisker wrote:
> While it might not be difficult to add a find() method to Iterable, why
>> limit it to
>> the find operation, and what about all the other operations available on
>> Stream?
>
>
> Good question. I would say it's a
I'm also thinking about something:
If `T find()` gets implemented on `Iterable` with the contract that
this method always ends, this implies that the amount of elements
available in the Iterable is finite, which makes it possible to define
a `int size()` by providing a trivial predicate.
This woul
Hi all,
Correct me if I'm wrong, but isn't the goal of Iterable be used as
argument in a enhanced for-loop, that is: just allow a enhanced
syntax.
(Similarly, AUtoCloseable is what allows the try-with-resource syntax;
Throwable is what allows the throw syntax)
As such, isn't it out of scope of It
Hi Nir,
at first I thought "Wow, it would be really cool to have that method in
Iterable! Why isn't it there already?"
But after thinking about it, I'm now convinced that it would be a bad
idea. Because it extends the scope of this small, tiny Iterable
interface to something bigger which it
>
> While it might not be difficult to add a find() method to Iterable, why
> limit it to
> the find operation, and what about all the other operations available on
> Stream?
Good question. I would say it's a matter of how much it is used and what
it takes to implement it. The find operation is a
>
> But a Stream cleanly separate the lazy side effect free API from the
> mutable one (Collection) and can be optimized better by the VM (it's a push
> API instead of being a pull API).
No doubt, but a stream also creates overhead and is more cumbersome to use
in the example I gave. Of course, I
On 9/16/20 1:59 PM, Remi Forax wrote:
- Mail original -
De: "Nir Lisker"
À: "core-libs-dev"
Envoyé: Lundi 14 Septembre 2020 20:56:27
Objet: 'Find' method for Iterable
Hi,
This has probably been brought up at some point. When we need to find an
item in a collection based on its p
- Mail original -
> De: "Nir Lisker"
> À: "core-libs-dev"
> Envoyé: Lundi 14 Septembre 2020 20:56:27
> Objet: 'Find' method for Iterable
> Hi,
>
> This has probably been brought up at some point. When we need to find an
> item in a collection based on its properties, we can either do it
12 matches
Mail list logo
