On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote:
> Currently, when the stream holds a resource, it's necessary to wrap it with
> try-with-resources. This undermines the compact and fluent style of stream
> API calls. For example, if we want to get the `List` of files inside the
> direct
Hi,
On 11/10/2021 20:42, John Rose wrote:
To summarize: We can (and should) try to model “close-debt”
using interfaces. Doing so opens up the usual cans of worms
with interoperability and exceptions, but still gives us a
model we can contemplate. We can (and should) contemplate
how such a mod
Oh, sorry, I found that I misunderstood the closing time. I tried it
in the wrong way, so I came to the wrong conclusion.
Thank you for your reminder.
- Original Message -
> From: "Glavo"
> To: "Tagir F.Valeev"
> Cc: "core-libs-dev"
> Sent: Samedi 16 Octobre 2021 06:25:40
> Subject: Re: RFR: 8274412: Add a method to Stream API to consume and close
> the stream without using try
I don't think it is a perfect solution to combine the close operation
with the terminator operation, because there are similar issues
in the intermediate operation.
Consider this use case (for example only):
try (var stream = Files.list(path)
.flatMap(dir -> {
try {
Hello!
> I am not really sure we’ve gotten the right idiom here yet. I’d like to slow
> down a bit before making an API decision.
>
> What id suggest is capturing the proposed api and spec on list, and let’s let
> this sit and bake for a bit longer. My sense is that something better may
> wel
se"
> To: "Paul Sandoz" , "Brian Goetz"
> , "Tagir F.Valeev"
>
> Cc: "core-libs-dev"
> Sent: Lundi 11 Octobre 2021 20:42:20
> Subject: Re: RFR: 8274412: Add a method to Stream API to consume and close
> the stream without using try-with
So the purpose of TWR is to hold an object with a “close-debt”
(debt of a future call to close) and pay it at the end of a block,
sort of like C++ RAII (but also sort of not).
But fluent syntaxes (which I like very much and hope to see
more of in the future!) don’t play well with blocks, so if a
f
Hi Tagir,
Do you mind if we slow down on this and let the idea bake somewhat, captured in
this thread/issue/PR(draft).
I am always a little wary of compact-only or fluent-only methods, as I find
them harder to justify. In this case I think there might be something more with
regards to a patter
I am not really sure we’ve gotten the right idiom here yet. I’d like to slow
down a bit before making an API decision.
What id suggest is capturing the proposed api and spec on list, and let’s let
this sit and bake for a bit longer. My sense is that something better may well
emerge if we do
- Original Message -
> From: "Tagir F.Valeev"
> To: "core-libs-dev"
> Sent: Lundi 4 Octobre 2021 08:51:55
> Subject: RFR: 8274412: Add a method to Stream API to consume and close the
> stream without using try-with-resources
> Currently,
On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote:
> Currently, when the stream holds a resource, it's necessary to wrap it with
> try-with-resources. This undermines the compact and fluent style of stream
> API calls. For example, if we want to get the `List` of files inside the
> direct
Currently, when the stream holds a resource, it's necessary to wrap it with
try-with-resources. This undermines the compact and fluent style of stream API
calls. For example, if we want to get the `List` of files inside the directory
and timely close the underlying filehandle, we should use some
13 matches
Mail list logo
