raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11
pekko/akka-stream/src/main/scala/akka/stream/scaladsl2/Sink.scala

19 lines
533 B
Scala
Raw Normal View History

=str #15755 #15756 rework Source/Sink materialization The philosophy is that the FlowMaterializer has complete control over how it interprets the AST, no restrictions. Therefore it only involves one specified method: materialize() which returns a MaterializedFlow. Within the ActorBasedFlowMaterializer we materialize Sources and Sinks that implement the specified SimpleSource/SourceWithKey interfaces (same for Sinks), others are not supported. These traits are extensible and they require that an ActorBasedFlowMaterializer is passed into the factory methods. Other materializers can of course interpret these AST nodes differently, or they can use the actor-based facilities by creating a suitable materializer for them to use. This means that everything is fully extensible, but the infrastructure we provide concretely for ourselves is built exactly for that and nothing more. Overgeneralization would just lead nowhere. Also made FutureSink isActive and implement it using a light-weight Subscriber instead of a Flow/Transformer.
2014-09-03 21:54:18 +02:00
/**
* Copyright (C) 2014 Typesafe Inc. <http://www.typesafe.com>
*/
package akka.stream.scaladsl2
!str #15977 Rename and change types in the new DSL * Cleaned up type signatures * Changed names of Source/Sink/ProcessorFlow to Tap/Drain/Pipe * Introduced new Source/Sink/Flow * Made all Pipe types package private * Changed the TypeGraph DSL to work on Flow/Sink/Source
2014-10-02 17:32:08 +02:00
import org.reactivestreams.Subscriber
!str #15604: Removal of default fanout behavior
2014-09-01 13:30:15 +02:00
!str #15977 Rename and change types in the new DSL * Cleaned up type signatures * Changed names of Source/Sink/ProcessorFlow to Tap/Drain/Pipe * Introduced new Source/Sink/Flow * Made all Pipe types package private * Changed the TypeGraph DSL to work on Flow/Sink/Source
2014-10-02 17:32:08 +02:00
import scala.language.implicitConversions
=str #15755 #15756 rework Source/Sink materialization The philosophy is that the FlowMaterializer has complete control over how it interprets the AST, no restrictions. Therefore it only involves one specified method: materialize() which returns a MaterializedFlow. Within the ActorBasedFlowMaterializer we materialize Sources and Sinks that implement the specified SimpleSource/SourceWithKey interfaces (same for Sinks), others are not supported. These traits are extensible and they require that an ActorBasedFlowMaterializer is passed into the factory methods. Other materializers can of course interpret these AST nodes differently, or they can use the actor-based facilities by creating a suitable materializer for them to use. This means that everything is fully extensible, but the infrastructure we provide concretely for ourselves is built exactly for that and nothing more. Overgeneralization would just lead nowhere. Also made FutureSink isActive and implement it using a light-weight Subscriber instead of a Flow/Transformer.
2014-09-03 21:54:18 +02:00
import scala.annotation.unchecked.uncheckedVariance
/**
!str #15977 Rename and change types in the new DSL * Cleaned up type signatures * Changed names of Source/Sink/ProcessorFlow to Tap/Drain/Pipe * Introduced new Source/Sink/Flow * Made all Pipe types package private * Changed the TypeGraph DSL to work on Flow/Sink/Source
2014-10-02 17:32:08 +02:00
* A `Sink` is a set of stream processing steps that has one open input and an attached output.
* Can be used as a `Subscriber`
=str #15755 #15756 rework Source/Sink materialization The philosophy is that the FlowMaterializer has complete control over how it interprets the AST, no restrictions. Therefore it only involves one specified method: materialize() which returns a MaterializedFlow. Within the ActorBasedFlowMaterializer we materialize Sources and Sinks that implement the specified SimpleSource/SourceWithKey interfaces (same for Sinks), others are not supported. These traits are extensible and they require that an ActorBasedFlowMaterializer is passed into the factory methods. Other materializers can of course interpret these AST nodes differently, or they can use the actor-based facilities by creating a suitable materializer for them to use. This means that everything is fully extensible, but the infrastructure we provide concretely for ourselves is built exactly for that and nothing more. Overgeneralization would just lead nowhere. Also made FutureSink isActive and implement it using a light-weight Subscriber instead of a Flow/Transformer.
2014-09-03 21:54:18 +02:00
*/
!str #15977 Rename and change types in the new DSL * Cleaned up type signatures * Changed names of Source/Sink/ProcessorFlow to Tap/Drain/Pipe * Introduced new Source/Sink/Flow * Made all Pipe types package private * Changed the TypeGraph DSL to work on Flow/Sink/Source
2014-10-02 17:32:08 +02:00
trait Sink[-In] {
=str #16028 Cleaned up ducplicate implementations of FlowOps
2014-10-03 14:21:18 +02:00
def toSubscriber()(implicit materializer: FlowMaterializer): Subscriber[In @uncheckedVariance] =
Flow[In].connect(this).toSubscriber()
=str #15755 #15756 rework Source/Sink materialization The philosophy is that the FlowMaterializer has complete control over how it interprets the AST, no restrictions. Therefore it only involves one specified method: materialize() which returns a MaterializedFlow. Within the ActorBasedFlowMaterializer we materialize Sources and Sinks that implement the specified SimpleSource/SourceWithKey interfaces (same for Sinks), others are not supported. These traits are extensible and they require that an ActorBasedFlowMaterializer is passed into the factory methods. Other materializers can of course interpret these AST nodes differently, or they can use the actor-based facilities by creating a suitable materializer for them to use. This means that everything is fully extensible, but the infrastructure we provide concretely for ourselves is built exactly for that and nothing more. Overgeneralization would just lead nowhere. Also made FutureSink isActive and implement it using a light-weight Subscriber instead of a Flow/Transformer.
2014-09-03 21:54:18 +02:00
}
Reference in a new issue Copy permalink