Actor receive macros

[JohnMurray]

Summary

Motivation

Test Plan

Notes

Just some thoughts about the work here and some considerations that went into it. What I would like out of actors with respect to message handling in the long-term:

• Behaviors

  • The ability to group message handlers of various types together
  • The ability to switch what the default behavior invoked when receiving a message
  • For this to be part of the basic / default API of an actor

• Ergonomics

  • Not having to deal with type-casting or conversions
  • Ability to write fairly normal looking code

Approach: Behavior Objects
It makes for a nice abstraction to model behaviors as objects that have a function that checks for message-type map and a function that does the processing. You can create these with macros to hide the ugly construction and then you can group and mix/match different behaviors together for composability.

How this approach lacks mostly has to due with the Rust borrow checker. You want each behavior to have mutable access to actor, but you can't capture this in a lambda. Further you can't pass in a self to the behavior of the actor type. So these limitations will add to an awkward API that macros wouldn't be able to fully hide.

Approach: Function Pointers
Instead of composing individual functions, just allow the user to define multiple "receive" functions and then switch between them at runtime. The default could just use the "receive" function that is already part of the actor trait.

Implementation wise, we would just need to track the function pointer in the CellState where we already store actor state and the actor itself.

The limitations again come down to Rust in particular. Function pointers are possible but, you can't take a function pointer to a method on a dyn trait. Also, the borrow checker again makes this a bit hard. We could use weak reference types, but those require the use of unsafe, which I want to fully avoid in this project.