RFR: 8180352: Add Stream.toList() method
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Nov 3 20:30:01 UTC 2020
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Stuart Marks" <smarks at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Mardi 3 Novembre 2020 20:54:57
> Objet: Re: RFR: 8180352: Add Stream.toList() method
>>> There is no value in making users remember which stream methods are
>>> null-hostile and which are null-tolerant; this is just more accidental
>>> complexity.
>> I think that ship has sailed a long ago.
>> Some collectors are null hostile, some are not.
>> You can make a point that a Collector is technically not the Stream API per se.
> Yes, and this is no mere "technical argument". A Collector is a collection of
> behaviors, governed by its own spec. The behaviors passed to stream operations,
> whether they be lambdas passed by the user (`.map(x -> x.hopeXIsntNull())`) or
> collector objects or comparators, are under the control of the user, and it is
> the user's responsibility to pass behaviors which are compatible with the data
> domain -- which the user knows and the streams implementation cannot know.
>> Because of that, i don't think we even have the choice of the semantics for
>> Stream.toList(), it has to be the same as stream.collect(Collectors.toList()).
> This doesn't remotely follow. (And, if it did, I would likely not even support
> this RFE.)
It seems you had an issue when replying to my mail, there is a paragraph before "Because"
> Let's take a step back,
> if we introduce a method toList() on Stream it will be used a lot, i mean really
> a lot, to the point where people will change the code from
> stream.collect(Collectors.toList()) to use stream.toList() instead.
> The spec of Collectors::toList was crafted to disavow pretty much anything other
> than List-hood, in part in anticipation of this addition.
>> But it can not be immutable too, for the same reason.
> Nope. The spec of toList() very clearly says: no guarantees as to the type,
> mutability, serializability, etc etc of the returned list. That doesn't mean
> that every method returning a List added to the JDK after Collectors::toList
> must similarly disavow all such guarantees.
> (In fact, we would be entirely justified to change the behavior of
> Collectors::toList tomorrow, to match the proposed Stream::toList; the spec was
> crafted to preserve this option. We probably won't, because there are too many
> programmers who refuse to read the specification, and have baked in the
> assumption that it returns an ArrayList, and this would likely just be picking
> a fight for little good reason, regardless of who is right.)
I don't understand your argument.
You know that you can not change the implementation of Collectors.toList(), and you also know that if there is a method Stream.toList(), people will replace the calls to .collect(Collectors.toList()) by a call to Stream.toList() for the very same reason but you want the semantics of Stream.toList() to be different from the semantics of Collectors.toList().
Rémi
More information about the core-libs-dev
mailing list