simulating multiple extends

Lately I have been getting into the habit of making my systems more modular, after finding that I was reimplementing a lot of stuff within multiple systems. For example, my physics engine could use both damage detection and removal detection (removeunit/explode/decay). If there were such thing as multiple extends in vJASS, something like this would be possible:


The advantage of this is that there would get to keep modularity of all of the systems. In other words, the physics engine would not even need to know about or require DamageDetect or StatusDetect. You could extend as much junk as you like to gain a struct composed of any kind of events you desire. I am not actually advocating a need for multiple extends in vJass, but I am trying to find the best method to go about simulating it, because having all of these events available within one struct is fun for the user.

Lately Vex has been talking about modules, and those can replace the use of multiple extends in certain situations. For example, you could have a timer module module which adds timer-related events, just by placing the module within the parent struct.

However, there is a limit to the complexity of modules, for example: if you tried to make DamageDetect a module which could be placed inside Object, you would run into the problem that the module needs its own onInit method, and there would probably be various other naming conflicts. Any sufficiently large system is not going to work well as a module because of these conflicts, plus the obscene amount of extra code it would generate by essentially copy and pasting your system inside of 5 other systems.

So then you come back to the situation where multiple extends would be nice. There is a way to simulate it, but it's very ugly. I call it "event forwarding." Here's an example:


I told you it was ugly, but it perfectly simulates multiple extends from the user's perspective, except they don't get to decide what their stuct implements. In this case, Object is hard-coded to gain the events from only StatusDetect and DamageDetect.

The obvious downside is the large amount of repetitive code (although not nearly as bad as forcing Object to implement its own damage detection and removal detection subsystems), but you could give StatusDetect and DamageDetect their own "event forwarder" textmacros if you wanted. The other issue is that it requires 2 TriggerEvaluates instead of 1, but honestly that's not a big deal even for a physics engine; people overestimate the effect that things like this will have on performance. And keep in mind, it is no worse performance than using a pseudo-trigger apprach, since that way would also need a TriggerEvaluate to call the specified UnitTakesDamage function in your system, and another TriggerEvaluate to call the onDamaged method for the individual object.

Anyway, I can't think of a better method to simulate multiple extends, anyone want to chip in with an idea or alternatives?

this could be awesome. Library has multiple requirements, so maybe struct should extend multiple too