How to properly structure actor's state

[Acácio Centeno]

Hello,

I'm developing an internal system that needs to perform some tasks at timed intervals and some others on-demand, some of which reacting to previous events. The actor model seems a perfect fit. I've used Scala/Akka a little in the past and found some of the concepts that Pulsar provides very similar, with the advantage of using Python (3.5), so I really would like to use it.

However, I'd like to structure the code in an "OOP way", that is, having one class to keep an agent's local state and exposing some methods as messages for inter-actor communication.

Is there a way to accomplish this? Something akin to this:

from pulsar import Actor, command, arbiter, spawn, send, ensure_future

# 1. Having a class to represent the actor
class Greeter(Actor):
    def __init__(self, EventHandler, Coverage, **kwargs):
        super().__init__(EventHandler, Coverage)
        # 3. Setting state with information received from an OOP-like spawn
        # (step 2 bellow)
        self.greeting = kwargs.get('greeting', 'Hello, ')

    # 4. Using command to mark methods instead of functions.
    @command()
    def msg(self, request, message):
        print(self.greeting + message['name'])
        return True



async def setup_actors(arbiter, **kwargs):
    # 2. Calling spawn with the class, and having it be the "actor implementation"
    greeter = Greeter.spawn('my_greeter', {'greeting': 'Hi there, '})
    reply = await greeter.send('msg', {'name': 'Foo'})
    print(reply)


def schedule_setup_actors(arbiter, **kwargs):
    ensure_future(setup_actors(arbiter, **kwargs))


arbiter(start=schedule_setup_actors).start()

Of course I could simulate it on the module level, that is, make an actor be implemented as a module, keep it's local state inside of it and export only the commands for communication. Having a command to explicitly initialize the state would probably make it equivalent to the OOP model, as long as I remember to always send this message before really using the actor for useful stuff, but the OOP model does seem more "comfortable" to me, and maybe easier for other members of my team to understand.

So, is it possible somehow to use pulse with this "OOP approach"? What would be the best alternative if not possible?

BR,

Acacio.

PS: Pykka is a much simpler implementation of the actor-model, without monitors and some other features, but it uses a model similar to what I'd like, so I added a small snippet attached should it make it more clear what the goal would be.

[lsbardel]

On Monday, January 30, 2017 at 6:33:24 PM UTC, Acácio Centeno wrote:

Hello,

Hi

 

I'm developing an internal system that needs to perform some tasks at timed intervals and some others on-demand, some of which reacting to previous events. The actor model seems a perfect fit. I've used Scala/Akka a little in the past and found some of the concepts that Pulsar provides very similar, with the advantage of using Python (3.5), so I really would like to use it.

Sounds a good idea

 

However, I'd like to structure the code in an "OOP way", that is, having one class to keep an agent's local state and exposing some methods as messages for inter-actor communication.

There are several way of doing this, directly inheriting from the Actor class is not one of them. the Actor class implements pulsar internal message passing and it is better to leave it alone.

 

So, is it possible somehow to use pulse with this "OOP approach"? What would be the best alternative if not possible?

One OOP approach to achieve your goal is to implement something along the lines of this remote snippet example.

In that example, you can create "remote" objects to keep state on a given actor by subclassing from the "Remote" class.

You can implement commands with methods prefixed with "remote_".

You spawn new remote objects with the spawn class method like you described.

Hope that helps