# What is this? Shared inbox for actor model?

In the past couple of months, I’ve been trying to critically think about how Alan Kay said OOP is really about the messages being passed, not the objects, a sentiment echoed in part by Sandi Metz in her workshops. I decided on a constraining definition of OOP, “Messages are passed to an unknown receiver from a known sender,” and eventually drew up something like the initial sketch in the linked document. I realized I was looking at something like the actor model used by Erlang; inbox messages are literally just labels, as I understand it, and the actor operates on the message labels it knows about. I remember reading a few opinion pieces on how Erlang implements OOP as Kay intended it, so I felt like I was on the right track.

But this isn’t quite like the actor model used in Erlang; as I understand it, each actor in Erlang has its own inbox and message passing is one-way. In this sketch, there’s instead a central inbox that all other objects are tightly coupled to; the central inbox’s public api is restricted to get, which takes a message label, and post, which takes a message object. Worker units can get message objects per labels they know, then perform work; source units can post message objects they know, and source units can also be workers or strictly just producers via Kafka, Redis, etc.

Message objects can have multiple rule objects associated with them; for instance, an ArrayMessage could say, “When a source posts this type of message, append it to an array; when a worker gets this type, return the entire array”; a StackMessage pushes and pops; a DelayedMessage instructs the inbox to return an error object if the minimum delay between gets hasn’t been reached; etc.

There’s nothing new under the sun, so this exists somewhere; I just don’t know what it is or how exactly to search for it, so I thought I could pick the brains of @Freemo and company.

Actor patterns are likely the direction OOP is headed. This post has me lost in thinking about some stuff i worked on with reactive pipes where all the OOP was ultimately in the message…

Do tell! That sounds exactly like what I was reaching for when I first started thinking about this

It is basically streams that convey information as streams do. The key is reactive back pressure. Check this out and then we can discuss if you have questions: https://en.wikipedia.org/wiki/Reactive_Streams

1 Like

Fascinating! I can tell this rabbit hole goes pretty deep

1 Like