1

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?

  • In your research, are the class names usually as generic as in your question, or is there a possibility that with proper naming, the empty message class describes a behavior that doesn't need additional parameters? – Bart van Ingen Schenau Jul 10 '17 at 11:33
  • @BartvanIngenSchenau the actual class name is Invoke, but while searching I mostly searched for empty message and similar search terms. It's just that, if this is a common pattern, I'd expect the framework to provide an overload that doesn't take a message parameter, or to provide something like Message.Empty. Perhaps I'm just being paranoid. – Stijn Jul 10 '17 at 11:38
2

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 ?

| improve this answer | |
  • That does look weird. I hadn't thought about it like that yet, messages being analoguous to method names. This does lead me to think that this generic Invoke class should be replaced with more descriptive classes, correct? – Stijn Jul 10 '17 at 12:29
  • 3
    @Stijn, precisely. What you're doing is basically calling remote objects. Refactor your "Invoke" to something meaningful would be an improvement on readability. – Machado Jul 10 '17 at 12:32
  • @Stijn at one time, what we now call "methods" were called "messages". – Frank Hileman Jul 12 '17 at 17:53
  • @FrankHileman, enough with the Smalltalk. Wink wink. – Machado Jul 12 '17 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.