Typed: Renaming deferred to setup #24548

This commit is contained in:
Johan Andrén 2018-02-15 13:40:26 +01:00 committed by GitHub
parent cdf36c21f5
commit 14bb878da1
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
48 changed files with 124 additions and 122 deletions

View file

@ -252,10 +252,10 @@ particular one using the `immutable` behavior decorator. The
provided `onSignal` function will be invoked for signals (subclasses of `Signal`)
or the `onMessage` function for user messages.
This particular `main` Actor is created using `Behaviors.deferred`, which is like a factory for a behavior.
This particular `main` Actor is created using `Behaviors.onStart`, which is like a factory for a behavior.
Creation of the behavior instance is deferred until the actor is started, as opposed to `Behaviors.immutable`
that creates the behavior instance immediately before the actor is running. The factory function in
`deferred` pass the `ActorContext` as parameter and that can for example be used for spawning child actors.
`onStart` is passed the `ActorContext` as parameter and that can for example be used for spawning child actors.
This `main` Actor creates the chat room and the gabbler and the session between them is initiated, and when the
gabbler is finished we will receive the `Terminated` event due to having
called `ctx.watch` for it. This allows us to shut down the Actor system: when

View file

@ -107,7 +107,7 @@ their registration order, i.e. the last registered first.
A message adapter (and the returned `ActorRef`) has the same lifecycle as
the receiving actor. It's recommended to register the adapters in a top level
`Behaviors.deferred` or constructor of `MutableBehavior` but it's possible to
`Behaviors.setup` or constructor of `MutableBehavior` but it's possible to
register them later also if needed.
The adapter function is running in the receiving actor and can safely access state of it, but if it throws an exception the actor is stopped.

View file

@ -231,6 +231,6 @@ Java
## Current limitations
* The `PersistentBehavior` can't be wrapped in other behaviors, such as `Behaviors.deferred`. See [#23694](https://github.com/akka/akka/issues/23694)
* The `PersistentBehavior` can't be wrapped in other behaviors, such as `Behaviors.setup`. See [#23694](https://github.com/akka/akka/issues/23694)