Why roll up world into esper module?

[sb3rg]

I am curious the reasoning behind why worlds were rolled up into the esper module? In working with this library and encountering this breaking change, I feel like I have to think a lot harder about this hidden context where as before it seemed much more explicit? Perhaps I am not thinking of world appropriately, which is why I feel the need to ask. Can you help me understand the reason behind the change? Perhaps it's my approach that hasn't been keeping in tune with the philosophy and design intent.

[benmoran56]

Hello Sean,

This thread here was the initial spark for it: https://github.com/benmoran56/esper/issues/87 The main driver for me was the improved performance, rather than getting away from OOP.

How many worlds are you using in your project? In my own, I tend to use only one world per game scene. That doesn't add much complication, because the context switching happens at the same time the scenes are changed. If I can understand your use case, perhaps we can find a solution to simplify things.

[sb3rg]

Thank you for pointing me in the right direction and bringing me along the thought process. I will refactor my code and try the new approach. It may very well end up cleaning up all of the floating world references. For my project, I am dealing with a lot of events and event data is much more transient vs needing to be transformed en masse by a processor. I will report back and see if the new approach makes it simpler for my use case, but I don't know as of yet.

[sb3rg]

So, in advancing my package towards incorporating 3.0 without an explicit "World," I noticed one big difference.

Because I have so many events that drive my design, I was using Worlds to dispatch process calls for those events. This is because I don't want all registered processes to execute when a certain type of event occurs. Therefore, I created these single responsibility worlds to handle these one-off events.

I realize that of course you have an event dispatch system available, but I was avoiding using it because it was about an order of magnitude slower than just creating a special purpose world and handling those particular events by calling process on them.

Now that I don't have explicit worlds, I am coerced towards using the event dispatching system (or so it seems). And when I migrated some of my code for testing the system performance decreased by about 40%.

I guess I could use the explicit call to "switch_world" to try and get back to my previous more performant version that side-steps the event system, but that feels clunky. Perhaps there will be a more performant event_dispatcher on the horizon? That way I can maintain my performance goals while adhering to 3.0 implicit worlds paradigm?

[sb3rg]

Marking closed given responses here: issue96