Can't you still create a bunch of events that all depend on each other? True modularity requires a shift in design--not a change in function signature, unless we're talking about two different things here.
I think we are a little bit...
As an example, the onUnitBuilt event in FFH does a boatload of things. It duplicates units for warrens, grants dwarves extra xp from brewerys, gives amurite units magic promotions and more.
Just adding all that to the onUnitBuilt event is simple. However, If I want to change warrens to produce three goblins instead of two, I'll then have to replace all of it, amurites, dwarves, golems et cetera.
In modular python the event is broken apart. There are several handlers for the onUnitBuilt event, and one can replace only the handler that duplicates units.
I'm sure that's possible in BUG too, just not mandatory. And I could have added the entire original onUnitBuilt to modular python, too.
The most added value is the refactoring of the monolithic CvEventManager into several tiny modular pieces.
There's also the specialized events, to replace multipronged if statements with fast dictionary lookups.
Yes, if you alter the SDK that fires the event by adding more parameters, old events can ignore them. I don't really know how often that would be useful as changing the parameters to an event typically means the old parameters weren't sufficient.
What you lose, however, is interoperability. If someone really likes an event using one system, they have to rewrite it significantly to get it to work in the other system. The beauty of CvCustomEventManager is that it didn't require you to alter how you write events; you just put them in a different module.
The original events are somewhat quirky, differing capitalization and so forth, and I wanted to add some more specialized events and make things easier to remember. By using dictionaries instead of tuples, one can remember a mnemonic key instead of an essentially random integer.
The part about adding parameters to a handler call is more about backwards compatibility for future versions of modular python.
And I think you are overstating the rewrite needed. Change the function signature, extract the arguments from a dict at the start instead of a tuple; ensure proper indentation, slap a decorator on the function and you're done.
While not significant, the conversion from a list to dictionary along with dictionary lookups to access parameters adds a small time penalty. I would be very cautious about increasing the runtime cost. Have modders been asking for the ability to have events whose parameters changed over time?
You save time only if you have multiple onUnitBuilt event handlers that need this information. If the event handlers don't need it, you pay the extra cost of looking it up needlessly.
Dictionary lookups are fast and hard to avoid; every time you access a variable or function or almost anything, there is at least one dictionary lookup, often more. I doubt one more explicit one is going to hurt.
And most, probably all, of the extra arguments in the data passed to the handlers were added because there already were multiple handlers that needed them. Ditto for the specialized event I mentioned earlier.
Here is where I favor clean coherent helper modules that make the coder's job easier.
I too favour clean coherent code, but I fail to see what that has to do with Fall From Heaven. (Not to denigrate the modders of Fall from Heaven, Fall Further et al. I much prefer working code over clean code.)
Seriously though, I don't know how helper modules would help with that.
This is what I was talking about. I see that it created a list to hold the return values from each handler, appending each onto the list as it called them. I didn't check what it returned to the SDK, but I assume it returned something from the list otherwise why build it? Again, I only glanced over this part.
Sometimes it's used, other times not. Depends on what the dll expects.
It hasn't seemed worth the bother of making two different helper funtions for the two cases. Needs profiling to tell for sure.
