[Dev]: Actor Generalization about squirecore

[TylerBloom]

I like the phrasing of "transient" and "permanent" actors a lot. That's a great idea.

As for API, the actor state is the part that "knows" if the state will ever terminate or not. This will allow us to restrict the scheduler accordingly. But more importantly, you should not be able to create a client that thinks it's talking to a permanent actor when it's talking to a transient actor (or, somewhat less importantly, visa versa). This is certainly possible. My larger concern is code duplication between different client types.

As for extension traits, see the Itertools trait in the itertools crate or the FutureEtx, StreamEtx, and SinkExt traits in the futures crate.

[akbulutdora]

Thanks for the detailed description of the problems. Here are my initial thoughts and questions

• Calling the persistence of the actors lifetime might get confusing in the long run. Should we consider an alternative? I propose transient and permanent actors and permanence of actors.

• For the API, could we allow the users to define what kind of an actor they want while building the actor (as a method on ActorBuilder)? The following seems like a good, intuitive syntax that might reduce cognitive load.

ActorBuilder::new().transient().launch();
ActorBuilder::new().persistent().launch();

// or we could get rid of `new` constructor in these cases
ActorBuilder::persistent().launch();
ActorBuilder::transient().launch();

ActorBuilder::new().launch(); // defaults to `persistent`

ActorBuilder::new().sink().launch();
ActorBuilder::new().stream().launch();

// as before, briefer constructors
ActorBuilder::stream().launch();
ActorBuilder::sink().launch();

// we could combine:
ActorBuilder::transient().sink().launch();

I haven't heard of extension traits before. I will check into them.