From a57235098beab186bf87ad4782738e92ef4c0795 Mon Sep 17 00:00:00 2001 From: Richard Imaoka Date: Tue, 15 May 2018 22:31:11 +0900 Subject: [PATCH] consistent wording; operator instead of combinator, in remaining places (#25101) --- .../scala/akka/actor/typed/scaladsl/ActorContext.scala | 2 +- .../main/scala/akka/stream/MaterializationBenchmark.scala | 8 ++++---- akka-docs/src/main/paradox/futures.md | 2 +- akka-docs/src/main/paradox/stream/stream-customize.md | 2 +- akka-docs/src/main/paradox/stream/stream-dynamic.md | 6 +++--- .../src/main/paradox/stream/stream-flows-and-basics.md | 2 +- akka-docs/src/main/paradox/stream/stream-quickstart.md | 4 ++-- akka-docs/src/main/paradox/stream/stream-testkit.md | 2 +- .../src/test/scala/akka/stream/FusingSpec.scala | 4 ++-- akka-stream/src/main/scala/akka/stream/ThrottleMode.scala | 2 +- .../src/main/scala/akka/stream/scaladsl/package.scala | 2 +- 11 files changed, 18 insertions(+), 18 deletions(-) diff --git a/akka-actor-typed/src/main/scala/akka/actor/typed/scaladsl/ActorContext.scala b/akka-actor-typed/src/main/scala/akka/actor/typed/scaladsl/ActorContext.scala index 2a0d8b31ee..028dcd8e9f 100644 --- a/akka-actor-typed/src/main/scala/akka/actor/typed/scaladsl/ActorContext.scala +++ b/akka-actor-typed/src/main/scala/akka/actor/typed/scaladsl/ActorContext.scala @@ -190,7 +190,7 @@ trait ActorContext[T] extends akka.actor.typed.ActorContext[T] { this: akka.acto /** * This Actor’s execution context. It can be used to run asynchronous tasks - * like [[scala.concurrent.Future]] combinators. + * like [[scala.concurrent.Future]] operators. * * This field is thread-safe and can be called from other threads than the ordinary * actor message processing thread, such as [[scala.concurrent.Future]] callbacks. diff --git a/akka-bench-jmh/src/main/scala/akka/stream/MaterializationBenchmark.scala b/akka-bench-jmh/src/main/scala/akka/stream/MaterializationBenchmark.scala index 1e20e20b59..0b4d59591e 100644 --- a/akka-bench-jmh/src/main/scala/akka/stream/MaterializationBenchmark.scala +++ b/akka-bench-jmh/src/main/scala/akka/stream/MaterializationBenchmark.scala @@ -16,9 +16,9 @@ import akka.Done object MaterializationBenchmark { - val flowWithMapBuilder = (numOfCombinators: Int) ⇒ { + val flowWithMapBuilder = (numOfOperators: Int) ⇒ { var source = Source.single(()) - for (_ ← 1 to numOfCombinators) { + for (_ ← 1 to numOfOperators) { source = source.map(identity) } source.to(Sink.ignore) @@ -73,11 +73,11 @@ object MaterializationBenchmark { final val subStreamCount = 10000 - val subStreamBuilder: Int ⇒ RunnableGraph[Future[Unit]] = numOfCombinators ⇒ { + val subStreamBuilder: Int ⇒ RunnableGraph[Future[Unit]] = numOfOperators ⇒ { val subFlow = { var flow = Flow[Unit] - for (_ ← 1 to numOfCombinators) { + for (_ ← 1 to numOfOperators) { flow = flow.map(identity) } flow diff --git a/akka-docs/src/main/paradox/futures.md b/akka-docs/src/main/paradox/futures.md index b8e6d3c1f1..2908be4df3 100644 --- a/akka-docs/src/main/paradox/futures.md +++ b/akka-docs/src/main/paradox/futures.md @@ -188,7 +188,7 @@ but if 2 or more `Future`s are involved `map` will not allow you to combine them @@snip [FutureDocSpec.scala]($code$/scala/docs/future/FutureDocSpec.scala) { #flat-map } -Composing futures using nested operators it can sometimes become quite complicated and hard to read, in these cases using Scala's +Composing futures using nested combinators it can sometimes become quite complicated and hard to read, in these cases using Scala's 'for comprehensions' usually yields more readable code. See next section for examples. If you need to do conditional propagation, you can use `filter`: diff --git a/akka-docs/src/main/paradox/stream/stream-customize.md b/akka-docs/src/main/paradox/stream/stream-customize.md index cc63cffce9..ceca0895ab 100644 --- a/akka-docs/src/main/paradox/stream/stream-customize.md +++ b/akka-docs/src/main/paradox/stream/stream-customize.md @@ -500,7 +500,7 @@ or the downstreams. Even for stages that do not complete or fail in this manner, The most general way of extending any `Source`, `Flow` or `SubFlow` (e.g. from `groupBy`) is demonstrated above: create a graph of flow-shape like the `Duplicator` example given above and use the `.via(...)` -combinator to integrate it into your stream topology. This works with all `FlowOps` sub-types, including the +operator to integrate it into your stream topology. This works with all `FlowOps` sub-types, including the ports that you connect with the graph DSL. Advanced Scala users may wonder whether it is possible to write extension methods that enrich `FlowOps` to diff --git a/akka-docs/src/main/paradox/stream/stream-dynamic.md b/akka-docs/src/main/paradox/stream/stream-dynamic.md index e1469e9f56..daa0cf4152 100644 --- a/akka-docs/src/main/paradox/stream/stream-dynamic.md +++ b/akka-docs/src/main/paradox/stream/stream-dynamic.md @@ -127,7 +127,7 @@ Java The resulting `Source` can be materialized any number of times, each materialization effectively attaching a new subscriber. If there are no subscribers attached to this hub then it will not drop any elements but instead -backpressure the upstream producer until subscribers arrive. This behavior can be tweaked by using the combinators +backpressure the upstream producer until subscribers arrive. This behavior can be tweaked by using the operators `.buffer` for example with a drop strategy, or attaching a subscriber that drops all messages. If there are no other subscribers, this will ensure that the producer is kept drained (dropping all elements) and once a new subscriber arrives it will adaptively slow down, ensuring no more messages are dropped. @@ -206,8 +206,8 @@ i.e. `int` greater than or equal to 0 and less than number of consumers. The resulting `Source` can be materialized any number of times, each materialization effectively attaching a new consumer. If there are no consumers attached to this hub then it will not drop any elements but instead -backpressure the upstream producer until consumers arrive. This behavior can be tweaked by using the combinators -`.buffer` for example with a drop strategy, or attaching a consumer that drops all messages. If there +backpressure the upstream producer until consumers arrive. This behavior can be tweaked by using an operator, +for example `.buffer` with a drop strategy, or attaching a consumer that drops all messages. If there are no other consumers, this will ensure that the producer is kept drained (dropping all elements) and once a new consumer arrives and messages are routed to the new consumer it will adaptively slow down, ensuring no more messages are dropped. diff --git a/akka-docs/src/main/paradox/stream/stream-flows-and-basics.md b/akka-docs/src/main/paradox/stream/stream-flows-and-basics.md index c950951166..c00a4e24cc 100644 --- a/akka-docs/src/main/paradox/stream/stream-flows-and-basics.md +++ b/akka-docs/src/main/paradox/stream/stream-flows-and-basics.md @@ -321,7 +321,7 @@ that holds a few elements for efficiency reasons. If your flow graphs contain cy may have been crucial in order to avoid deadlocks. With fusing these implicit buffers are no longer there, data elements are passed without buffering between fused stages. In those cases where buffering is needed in order to allow the stream to run at all, you will have to insert explicit buffers with the -`.buffer()` combinator—typically a buffer of size 2 is enough to allow a feedback loop to function. +`.buffer()` operator—typically a buffer of size 2 is enough to allow a feedback loop to function. @@@ diff --git a/akka-docs/src/main/paradox/stream/stream-quickstart.md b/akka-docs/src/main/paradox/stream/stream-quickstart.md index b3d6e94d62..0b8985384c 100644 --- a/akka-docs/src/main/paradox/stream/stream-quickstart.md +++ b/akka-docs/src/main/paradox/stream/stream-quickstart.md @@ -196,7 +196,7 @@ that running the streams happens in the background, asynchronously (this is the reason for the auxiliary information to be provided as a @scala[`Future`]@java[`CompletionStage`], in the future). The secret that makes this work is that Akka Streams implicitly implement pervasive flow control, all operators respect back-pressure. This allows the throttle -combinator to signal to all its upstream sources of data that it can only +operator to signal to all its upstream sources of data that it can only accept elements at a certain rate—when the incoming rate is higher than one per second the throttle operator will assert *back-pressure* upstream. @@ -313,7 +313,7 @@ Java In the previous section we were working on 1:1 relationships of elements which is the most common case, but sometimes we might want to map from one element to a number of elements and receive a "flattened" stream, similarly like `flatMap` works on Scala Collections. In order to get a flattened stream of hashtags from our stream of tweets we can use the `mapConcat` -combinator: +operator: Scala : @@snip [TwitterStreamQuickstartDocSpec.scala]($code$/scala/docs/stream/TwitterStreamQuickstartDocSpec.scala) { #hashtags-mapConcat } diff --git a/akka-docs/src/main/paradox/stream/stream-testkit.md b/akka-docs/src/main/paradox/stream/stream-testkit.md index b906cdf67d..446b91009d 100644 --- a/akka-docs/src/main/paradox/stream/stream-testkit.md +++ b/akka-docs/src/main/paradox/stream/stream-testkit.md @@ -26,7 +26,7 @@ flows and sinks. This makes them testable by wiring them up to other sources or sinks, or some test harnesses that `akka-testkit` or `akka-stream-testkit` provide. -## Built-in sources, sinks and combinators +## Built-in sources, sinks and operators Testing a custom sink can be as simple as attaching a source that emits elements from a predefined collection, running a constructed test flow and diff --git a/akka-stream-tests/src/test/scala/akka/stream/FusingSpec.scala b/akka-stream-tests/src/test/scala/akka/stream/FusingSpec.scala index 2665490610..39c9282f98 100644 --- a/akka-stream-tests/src/test/scala/akka/stream/FusingSpec.scala +++ b/akka-stream-tests/src/test/scala/akka/stream/FusingSpec.scala @@ -44,7 +44,7 @@ class FusingSpec extends StreamSpec { refs.toSet should have size (11) // main flow + 10 subflows } - "use multiple actors when there are asynchronous boundaries in the subflows (combinator)" in { + "use multiple actors when there are asynchronous boundaries in the subflows (operator)" in { Source(0 to 9) .via(snitchFlow) .flatMapMerge(5, i ⇒ Source.single(i).via(snitchFlow.async)) @@ -70,7 +70,7 @@ class FusingSpec extends StreamSpec { refs.toSet should have size (in.size + 1) // outer/main actor + 1 actor per subflow } - "use one actor per grouped substream when there is an async boundary around the flow (combinator)" in { + "use one actor per grouped substream when there is an async boundary around the flow (operator)" in { val in = 0 to 9 Source(in) .via(snitchFlow) diff --git a/akka-stream/src/main/scala/akka/stream/ThrottleMode.scala b/akka-stream/src/main/scala/akka/stream/ThrottleMode.scala index 62967d2c5a..b5b95bc283 100644 --- a/akka-stream/src/main/scala/akka/stream/ThrottleMode.scala +++ b/akka-stream/src/main/scala/akka/stream/ThrottleMode.scala @@ -5,7 +5,7 @@ package akka.stream /** - * Represents a mode that decides how to deal exceed rate for Throttle combinator + * Represents a mode that decides how to deal exceed rate for Throttle operator */ sealed abstract class ThrottleMode diff --git a/akka-stream/src/main/scala/akka/stream/scaladsl/package.scala b/akka-stream/src/main/scala/akka/stream/scaladsl/package.scala index 989ca46f48..e154c5d23e 100644 --- a/akka-stream/src/main/scala/akka/stream/scaladsl/package.scala +++ b/akka-stream/src/main/scala/akka/stream/scaladsl/package.scala @@ -44,7 +44,7 @@ import scala.compat.java8.FutureConverters * often than for corresponding transformations on strict collections like * [[List]]. *An important consequence* is that elements that were produced * into a stream may be discarded by later processors, e.g. when using the - * [[#take]] combinator. + * [[#take]] operator. * * By default every operation is executed within its own [[akka.actor.Actor]] * to enable full pipelining of the chained set of computations. This behavior