Does it make sense to have empty messages, in order to simply invoke an actor?

Question

I'm getting familiar with an existing Akka.NET codebase and the actor model itself, and I notice a number of actors are configured to receive empty messages and do their work.

class Invoke
{
}

class MyActor : ReceiveActor
{
    public MyActor()
    {
        Receive<Invoke>(i => /* do work */);
    }
}

The use of a custom Invoke class instead of a hypothetical framework-provided class makes me doubt this type of usage. I've tried finding info on Google, but various search terms yielded no interesting results.

Does this kind of usage make sense in the actor model? Perhaps I'm not using the right search terms? Or is the actor model being misused here?

Answer 1

I understand your question, but I'd like to give some food of thought here: Does it make sense have a "void" before the name of each method that does not return a value ? Like public void DoWork(); ?

The messaging pattern of Akka is a convention, making explicit for the programmer that he's calling an object somewhere asynchronously, and the convention states that you pass messages everywhere, even empty messages.

What's the difference between calling the method DoWork1() on a object or DoWork2() on the same object ? The name of the method, only.

As an exercise, think about the messages as the method names you want to run on the remote object. That's a good reason for not having a default Message.Empty, because that would mean that every object in your framework that does a no-return or no-parameter job would have to handle this message, and this can lead to confusion on the example above.

What if you have an Actor that handles 2 different no-parameters job ? Would you declare:

class MyActor : ReceiveActor
{
   public MyActor()
   {
      Receive<Message.Empty1>(i => /* do work 1 here */);
      Receive<Message.Empty2>(j => /* do work 2 here */);
   }
}

Doesn't it look/feel weird for you ?