raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11

=doc small adjustments for merging typed docs to master

Browse source
This commit is contained in:
Konrad `ktoso` Malawski 2017-05-22 14:19:20 +02:00
parent 17baf49fc7
commit d4c5b43c9d
1 changed files with 9 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

18
akka-docs/src/main/paradox/scala/typed.md
View file

@ -13,12 +13,12 @@ As discussed in @ref:[Actor Systems](general/actor-systems.md) (and following ch
sending messages between independent units of computation, but how does that sending messages between independent units of computation, but how does that
look like? In all of the following these imports are assumed: look like? In all of the following these imports are assumed:
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #imports } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #imports }
With these in place we can define our first Actor, and of course it will say With these in place we can define our first Actor, and of course it will say
hello! hello!
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #hello-world-actor } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #hello-world-actor }
This small piece of code defines two message types, one for commanding the This small piece of code defines two message types, one for commanding the
Actor to greet someone and one that the Actor will use to confirm that it has Actor to greet someone and one that the Actor will use to confirm that it has
@ -33,7 +33,7 @@ immutable because the behavior instance doesn't have or close over any mutable
state. Processing the next message may result in a new behavior that can state. Processing the next message may result in a new behavior that can
potentially be different from this one. State is updated by returning a new potentially be different from this one. State is updated by returning a new
behavior that holds the new immutable state. In this case we don't need to behavior that holds the new immutable state. In this case we don't need to
update any state, so we return :class:`Same`. update any state, so we return `Same`.
The type of the messages handled by this behavior is declared to be of class The type of the messages handled by this behavior is declared to be of class
`Greet`, which implies that the supplied function’s `msg` argument is `Greet`, which implies that the supplied function’s `msg` argument is
@ -54,7 +54,7 @@ wrapped scope—the `HelloWorld` object.
Now we want to try out this Actor, so we must start an ActorSystem to host it: Now we want to try out this Actor, so we must start an ActorSystem to host it:
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #hello-world } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #hello-world }
After importing the Actor’s protocol definition we start an Actor system from After importing the Actor’s protocol definition we start an Actor system from
the defined behavior. the defined behavior.
@ -150,7 +150,7 @@ a message that contains their screen name and then they can post messages. The
chat room Actor will disseminate all posted messages to all currently connected chat room Actor will disseminate all posted messages to all currently connected
client Actors. The protocol definition could look like the following: client Actors. The protocol definition could look like the following:
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-protocol } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-protocol }
Initially the client Actors only get access to an `ActorRef[GetSession]` Initially the client Actors only get access to an `ActorRef[GetSession]`
which allows them to make the first step. Once a client’s session has been which allows them to make the first step. Once a client’s session has been
@ -167,7 +167,7 @@ full protocol that can involve multiple Actors and that can evolve over
multiple steps. The implementation of the chat room protocol would be as simple multiple steps. The implementation of the chat room protocol would be as simple
as the following: as the following:
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-behavior } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-behavior }
The core of this behavior is stateful, the chat room itself does not change The core of this behavior is stateful, the chat room itself does not change
into something else when sessions are established, but we introduce a variable into something else when sessions are established, but we introduce a variable
@ -208,7 +208,7 @@ problematic, so passing an `ActorRef[PostSessionMessage]` where
In order to see this chat room in action we need to write a client Actor that can use it: In order to see this chat room in action we need to write a client Actor that can use it:
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-gabbler } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-gabbler }
From this behavior we can create an Actor that will accept a chat room session, From this behavior we can create an Actor that will accept a chat room session,
post a message, wait to see it published, and then terminate. The last step post a message, wait to see it published, and then terminate. The last step
@ -218,7 +218,7 @@ running behavior into the terminated state. This is why here we do not return
Since `SessionEvent` is a sealed trait the Scala compiler will warn us Since `SessionEvent` is a sealed trait the Scala compiler will warn us
if we forget to handle one of the subtypes; in this case it reminded us that if we forget to handle one of the subtypes; in this case it reminded us that
alternatively to `SessionGranted` we may also receive a alternatively to `SessionGranted` we may also receive a
:class:`SessionDenied` event. `SessionDenied` event.
Now to try things out we must start both a chat room and a gabbler and of Now to try things out we must start both a chat room and a gabbler and of
course we do this inside an Actor system. Since there can be only one guardian course we do this inside an Actor system. Since there can be only one guardian
@ -227,7 +227,7 @@ want—it complicates its logic) or the gabbler from the chat room (which is
nonsensical) or we start both of them from a third Actor—our only sensible nonsensical) or we start both of them from a third Actor—our only sensible
choice: choice:
@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-main } @@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-main }
In good tradition we call the `main` Actor what it is, it directly In good tradition we call the `main` Actor what it is, it directly
corresponds to the `main` method in a traditional Java application. This corresponds to the `main` method in a traditional Java application. This