Closed Daenyth closed 4 years ago
I like the general idea of exposing the materialized value as FS2 stream instead of providing a callback (which makes composition on FS2 side hard or impossible). But for better symmetry with Akka Sink|Source|Flow plus materialized value what do you think about adding converters like toSinkMat
, toSourceMat
and toPipeMat
returning a tuple containing the converted Sink|Stream|Pipe plus a Stream that emits the single materialized value. For example (in pseudocode):
val (fs2Sink, fs2MatStream) = akkaSink.toSinkMat()
val (fs2Source, fs2MatStream) = akkaSource.toSourceMat()
...
This would allow applications to compose the result tuple elements as they like in FS2. Also, when converting an Akka Source to an FS2 Stream, the Stream element type and the materialized value type usually differ and cannot be combined into a single Stream (unless you use something like Either[A,B]
as element type but this has less symmetry to Akka Streams).
The onMaterialization
parameter of existing converters toSink
, toStream
and toPipe
could then be removed/deprecated. WDYT?
That's not a bad idea - we can have toFoo(implicit ev: Mat =:= NotUsed)
and toFooMat
returning the tuple. That sounds like a nice interface!
Sounds good, would be great to see a PR! I'm not sure if toFoo(implicit ev: Mat =:= NotUsed)
is too restrictive but we can discuss that in the PR later. Thanks for your useful proposal!
I don't think it's too bad - If there's a used Mat
value, I think discarding it should be done explicitly, hence the Discard
constant that I'd put in the package object to be imported with the implicits
I have a WIP proposal here: https://github.com/krasserm/streamz/compare/master...Daenyth:matvalue
I'm playing around a bit to see if I can keep the single method name next, while still having the differing return types based on Mat
I don't think it's too bad - If there's a used
Mat
value, I think discarding it should be done explicitly, hence theDiscard
constant that I'd put in the package object to be imported with the implicits
Understood. If discarding can be done explicitly than it's fine. I thought users are forced to use toFooMat
then. So please ignore my previous concern then.
The problem: Akka streams have materialized values, but the default
.toStream()
or.toSink()
discard them. I've created race conditions by converting sinks with a materialized Future result and not waiting on that future.Ad-hoc solution: I created this:
The problem with my approach is that the user is still required to realize they need the alternate converter method.
A more comprehensive solution: I'd like to make a breaking API change before we make the 1.x release.
Proposed:
This guarantees that a caller must either provide an explicit
onMaterialization
, for whichDiscard
will be wildcard imported for convenience, or if they don't want to pass one, thatM
must beNotUsed
.I haven't tested this yet, but I believe the general approach should work.
If you're willing to take this, I'll send a PR implementing it