Misleading approach to actor initialization

[stanislav-chetvertkov]

PreStart signal has been removed from it and it was suggested to use Actor.deferred instead
But it can be misleading for the newcomers.

Here is the example, lets say I want to schedule a message to ctx.self from an actor
This is the correct approach

sealed trait MyProtocol
case object StartWork extends MyProtocol

def prepare(): Behavior[MyProtocol] = Actor.deferred[MyProtocol]{ ctx =>
    ctx.schedule(1.second, ctx.self, StartWork)
    init()
}

def init(): Behavior[MyProtocol] = Actor.immutable[MyProtocol] { (ctx, msg) =>
    msg match {
        case StartWork =>
            // Message was sent
            Actor.same
    }
}

But my initial incorrect approach was

sealed trait MyProtocol
case object StartWork extends MyProtocol

def init(): Behavior[MyProtocol] = Actor.immutable[MyProtocol] { (ctx, msg) =>
    ctx.schedule(1.second, ctx.self, StartWork)

    msg match {
        case StartWork =>
            // Was NOT triggered
            Actor.same
    }
}

I guess my problem with it that it is really easy to make a mistake, because It looks like I have some space for initialization logic after (ctx, msg) => part

Also might be not clear that ctx.self inside of deferred is the same as in underlying immutable block

P.S. I know that there was already a lot of talks related to that. But I just sharing my feedback and the problem that many can potentially face with this version of API

[rkuhn]

Thanks for your feedback! Which places of potential documentation have you visited before trying this out? It would be good to know where we can place a hint that alerts users to this potential oversight(*).

(*) it is a user oversight since technically there cannot really be space for initialization within a block that receives a msg parameter

[stanislav-chetvertkov]

Hi Roland,
http://akka.io/blog/2017/05/05/typed-intro

[stanislav-chetvertkov]

there cannot really be space for initialization within a block that receives a msg parameter I know, but I guess a match statement which is usually present makes it look like something else...
Maybe it is just looks unusual(like a block) after working a lot with untyped api

[rkuhn]

Right, I know that it looks tempting; what I meant was that we couldn’t possibly implement things such that initialization becomes supported in that fashion.

If you have not looked at anything else besides the blog post (no API docs, no reference docs, no IDE tooltips) then the only place where we can improve the situation is that blog post (we should probably also add a note to all these other places, but I fear most users will not read them).

[stanislav-chetvertkov]

I also read the official docs but there was no clarification that ctx.self in deferred points to the same place as context in nested immutable section, although now it looks obvious to me

[rkuhn]

Ah, good: can you suggest an exact placement of such clarification? Easiest might be a PR (can be done on github with the edit feature).

[stanislav-chetvertkov]

ok, I will