Closed tqwewe closed 10 months ago
Rather than doing this, could you define a SimpleActor
trait and an adapter type which implements Actor
which handles all the details for SimpleActor
-implementing types? That would let you use the simplified API where applicable but still preserve the full API for when its needed.
I could do that, though might it add too many options and add complexity by having two different ways to implement an actor? If the change I proposed isn't something the project wants to go with, I think I'd prefer just continuing to use ractor as it is without the new trait added.
The original reasons for building out separate types I think still holds and this is a pretty major overhaul for any downstream use-cases. I agree with @jsgf and would prefer to build a wrapper for those wanting this kind of API.
Related to https://github.com/slawlor/ractor/issues/56#issuecomment-1659546195
This PR is a draft which removes the
State
andArguments
associated types from theActor
trait, and instead uses Actors directly as the state.This simplifies things quite a lot.
The biggest concern may be that starting an actor that panics will panic outside the actor. To solve this, I added some methods
spawn_with
andspawn_linked_with
which catch panics and let you start an actor in a closure.If
PingPong::new()
panics for whatever reason, then the panic will be handed and a startup error will be returned.