Event handlers set within a function don't remain once the block scope exits. Why use weak references here?

[sb3rg]

Spent hours debugging why my handlers weren't triggering. Is this a bug or a feature?

import esper

# like a Processor, but for my project's purposes not
class DummyHandler():
    def __init__( self, world ):
        self.WORLD = world

    def handle( self, state ):
        pass

def _dummy_init():
    handler = DummyHandler( esper.World())
    esper.set_handler( "WillNotSet", handler.handle )

_dummy_init()
assert not "WillNotSet" in esper.event_registry

handler = DummyHandler( esper.World() )
esper.set_handler( "WillSet", handler.handle )
assert "WillSet" in esper.event_registry

May I ask why you wouldn't want handlers to remain registered as an event after leaving block scope?

[benmoran56]

This is intentional, and the behavior is mentioned in the readme. Event dispatchers do not own the instance of the attached handler/observer, and should not hold a reference to keep it alive. Within the current design, there would be no other way to remove the handler that is set in _dummy_init. A more sophisticated design could be done, but it's out of scope for esper. The included event dispatching is really on here to facilitate event passing between Processors, which is the common use case.

[sb3rg]

Got it. Thank you for helping me understand.

I find that processors are really meant to handle game architectures it seems, as by design they are intended to vertically transform a grouping of entities en masse at each frame tick. My use case is almost exclusively events and events usually are the interaction between singular entities within the model, therefore making Processors almost overkill, especially in light of v3.0.

Before 3.0 I was creating individual worlds just to handle individual types of transformations and I imagine my code base would have become polluted with floating one-off worlds just perform process calls of a certain family or event. To migrate to 3.0, I've had to dissolve all these worlds and combine them and introduce "Handlers" in conjunction with the event system. With use-cases that advance event-driven state by state vs fixed time interval, avoiding Processors seems to be the favored pattern (now that worlds aren't explicit)

Do you have any thoughts on this? Apologies for all the questions. I am just really excited about using the esper library and while I've used other languages I'm still relatively new to Python (< 9 mo).

[benmoran56]

I find that processors are really meant to handle game architectures it seems, as by design they are intended to vertically transform a grouping of entities en masse at each frame tick.

Essentially, this is the main design point of ECS libraries, and what dictates the design of esper. The Processors themselves don't even care about entities as a whole - they are only interested in performing specific operations on single (or specific combinations) of Components.

My use case is almost exclusively events and events usually are the interaction between singular entities within the model, therefore making Processors almost overkill, especially in light of v3.0.

What you're describing is not really an Entity System. Which isn't to say it's wrong, but it's something different. Not every game fits the ECS pattern well. Lots of games use a combination of patterns in the same package. Writing the scene management code in ECS doesn't make sense IMO.

As an aside, you might find this talk by Bob Nystrom interesting: https://www.youtube.com/watch?v=JxI3Eu5DPwE

[sb3rg]

Thank you! Loved the video! Very interesting and it certainly gives me some food for though.