Is there a way to implement "become" in Stakker?

[hardliner66]

I think the ergonomics of Stakker are really nice, but one thing is missing for me, coming from CAF, namely become.

In CAF an actor can use become to change it's behavior, which can be used to implement different states of a state machine.

For instance:
Imagine you have a protocol that can send two message types. In CAF you can create two behaviors with the same interface and change the behavior at runtime. So you can have a ParseHeaderPackageActor which can become a ParseDataPackageActor and when it's done, it can use unbecome to go back to the previous behavior.

So my question is, if I can somehow replicate that in Stakker. I already tried creating an actor from a trait, but switching behavior doesn't seem to work there.

I can probably find a way to implement this using either an additional actor or with using an enum for the internal state, but it would be cool if there were a stakker way to do this.

[uazu]

That's an interesting idea. It would mean going through a kind of redirect table depending on what "identity" the actor is taking at that time. In Stakker, actor method calls are resolved statically at compile-time, so that everything possible can be optimised down. So the question is whether traits can help with this. (See https://uazu.github.io/stakker/g-traits.html about some different approaches to traits with actors.) The problem being that the trait vtable is captured when the actor is created. Rust doesn't give us a way to switch that at runtime after it is captured. However maybe it could be done with something like Actor<Cell<Box<dyn Trait>>>, to let us switch the Box<dyn Trait> at runtime via internal mutability.

I guess "become" is straightforward if you're doing method lookup at runtime (which Stakker isn't), so it means a few more hoops have to be jumped through to make it work for Stakker. The extra indirection to allow switching "identities" ends up being explicit, at least how thing are at present.

So the quick answer is that no I haven't looked at doing this, and there isn't any built-in Stakker mechanism to enable it. It would be good if a way could be found, though, that looks neat in the finished code. I will have a think.

[hardliner66]

Well, Stakker already allows late initialization by using actor_new and calling the initialization later on. If this could be done again and would run as highest priority (before any other calls) it would be enough to implement become. Especially if it could somehow be limited to only work from within the actor. Otherwise the behavior could be changed from the outside.

So maybe there would be a way to return to the prep stage with a new initialization already queued up. If we want to be fancy, we could store a stack of old behaviors and pop them with unbecome, but this could be behind a feature so it wont take up space where it's not needed.

[uazu]

You can think of the late initialization as changing an Option<MyActor> from None to Some (although actually it's a bigger enum than Option), so that doesn't allow the type implementing the actor to be changed. The type is established at compile-time. (This means that there is a lot of knowledge at compile-time, which the compiler uses to inline and optimise the code: deferred calls with constant arguments often result in using a specialised/optimised version of the call handling code, just thanks to RustC inlining and LLVM optimisation).

The only way to implement changing the backing type would be through some kind of indirection, e.g. switching a Box<dyn Trait> from one to another. Actually compared to using indirection, I think using an enum within the actor may be more ergonomic. I will write a fuller response separately about this.

[uazu]

So if we were to approach this through traits, that would mean defining a trait for the actor's API, and then having several implementations of that trait for the different modes that the actor could be in. The actor would contain a Box<dyn Trait> to allow switching the implementation when necessary. Then there would be some glue required to connect it all up, but that could possibly be automated with a macro or a wrapping structure (via Deref). Then changing modes ("become") would mean replacing one Box with another.

The alternative would be to have an enum for the different modes kept inside the actor structure. Then for each of the methods, you'd need a match on that enum to decide what to do. Since Rust permits data to be associated with enum variants, then the match can pick up access to the variant's data with Variant(ref mut p) => { ... } or whatever. So this is a lot easier and safer than it might be in C++. Switching modes just means giving the enum a new value.

So it's a matter of how you'd prefer to structure the code. With an enum and match, all the code is organized under the method calls. With a trait and separate implementations, it's all grouped under the implementations. I think there would be more duplication using a trait, since there is a definition and then all those signatures have to be repeated for the implementations. The duplication when using an enum is just the match variants. The enum approach may have an advantage when some handling is shared between modes, since state related to that shared handling could be kept outside of the enum.

If you're still interested in the trait approach, I could perhaps try and put together an example. I'm not sure how exactly the trait methods will inform the glue code when to switch modes. Maybe an additional argument or return value. Anyway let me know if you're interested in trying this and need me to put something together.