Round of Operator promotion from Stream to Flux/Mono about reactor-core HOT 11 CLOSED

Mono#after already exists, isn't it?
I am ok for most of them, except for repeat() I am not sure for this one. What are the most common use cases for it?

from reactor-core.

Mono#after exists but doesn't react only on complete (it does react on error too). Both behavior being acceptable, this is a valid user request (not mine). We need an alias with a boolean to precise if errors are also triggering the Supplier.

from reactor-core.

Ok I see the need, but I don't realy like the API proposed. What about adding just Mono<Void> afterComplete()?

from reactor-core.

afterComplete() works too , updating

from reactor-core.

👍

from reactor-core.

I'm sure all of these come from actual cases encountered but I'm not in favor of voting in bulk. At the risk of extra formality could we follow a more regular routine where a ticket is created (preferably by whoever has the case) to request an operator? This allows a more focused discussion and hopefully better decisions. It also leaves a trail for anyone to see or comment on. If we agree I'd be happy to make the case for justOrEmpty and cache.

from reactor-core.

Sure @rstoyanchev I actually just tried to keep them somewhere and didn't take the time to do separate issues.

from reactor-core.

Okay so I've created #25 and #26. Let's close this one and have separate tickets drive the request for additional ones. They all look useful, and have some thoughts on a few, but since we are trying to keep a distinction between Core and Stream, it would be better if we discussed them in context individually.

from reactor-core.

Ok @nebhale if you can re-refer to afterComplete, single and repeatWhen in three separate issues to keep track of it 👍

from reactor-core.

@sdeleuze if you can track take , filter and anything else you had in mind in separate issues too.

from reactor-core.

Extra note, implementing mono operators only actually save the operator cost most of the time, double implementing to Flux forces to migrate operator as in Stream to Core (StreamFilter, StreamXXX -> FluxFilter ... ). That's what we do for Mono#where , a simple filter implementation using then instead of a MonoFilter concrete operator. The general rule is that flatMap / then are pretty much efficient at implementing anything except it makes users pay for its machinery overhead.

from reactor-core.