paralyzed by engine architecture problems

[s-ol]

I don't understand how your proposed code would work since dispatcher.lua requires event_handlers.lua requires dispatcher.lua... etc. It's still circular.

The issue is how to dispatch events from within the event handlers. Or if I even should be doing that.

if you use globals like he proposed everything is solved, you don't need to require them again. In dispatcher.lua you just call functions on event_handlers like event_handlers.doStuff() and in event_handler.lua you just call functions like dispatcher.new_event("player:death", {x=x, y=y}).

[undef]

Well the files don't need to require each other, because they are both being required by the main.lua in my example.
The modules returned are stored in the global variables "dispatcher" and "event_handlers" and should therefore be visible to each other (and in that case, also to anything else that has access to the global environment).

The intention of your code was understandable, I just didn't get the value/object in the event.
I don't handle events that way personally, so I wasn't that quick to grasp how you do it.

[r-hughes]

ah, I understand now. I'll think about doing it that way but I try to avoid globals as much as I can.

[s-ol]

ah, I understand now. I'll think about doing it that way but I try to avoid globals as much as I can.

if you are going to require "dispatcher" in every file then there is no reason not to use globals. globals aren't always a bad thing (just like OOP isn't necessarily bad), of course they are often misused but that doesn't mean they don't have a purpose. If you need something everywhere, then globals are the perfect fit.

IMO avoiding something at all costs is at least as bad as over-engineering with OOP. No concept is inherently bad.

[r-hughes]

ah, I understand now. I'll think about doing it that way but I try to avoid globals as much as I can.

if you are going to require "dispatcher" in every file then there is no reason not to use globals. globals aren't always a bad thing (just like OOP isn't necessarily bad), of course they are often misused but that doesn't mean they don't have a purpose. If you need something everywhere, then globals are the perfect fit.

IMO avoiding something at all costs is at least as bad as over-engineering with OOP. No concept is inherently bad.

I literally only need it in two places (the event handlers and the game update functions). I'm not sure where the idea that I need it *everywhere* came from. It's two files, guys.

[airstruck]

I try to avoid globals as much as I can.

In my opinion the only time globals are appropriate is when addressing cross-cutting concerns, for example a "debug" or "log" global. I've tried to get feedback from the community about this opinion but haven't had any response one way or the other. If you happen to share that opinion, you might want to think about whether event stuff represents a cross-cutting concern (I don't think it does; then again I suppose you could be using events in a very generalized way).

I don't think the obvious solution has been suggested yet. You don't have to require module A when module B is loaded, you can do it later, as soon as the module is needed.

Code: Select all

-- dispatcher.lua

local dispatcher = {}

local event_handlers

function dispatcher.dispatch_event(dispatcher, event, world)
    if not event_handlers then event_handlers = require 'event_handlers' end
    -- find listeners and call the appropriate event handler
end

return dispatcher

This can be done in either or both of the modules with circular dependencies. In general, though, circular dependencies might be a sign that you've got some dependencies pointing in the wrong direction and it might not be a bad idea to rethink your design.

[r-hughes]

not a bad idea.

i think maybe i just won't raise events within the events handlers... then the issue resolves itself!