I quickly sketched out an idea of how the interrupt_before method should work, and made some minor modifications to make the should_fire computation a bit more concise and readable:
I also included a bit of code to show that it's relatively easy to have conditional interrupts: each event instance has access to its corresponding object, and so can make decisions about which interrupts (if any) to add.
In gameplay-potential terms, this means you can have things like forcefields around interactive objects. In this case, turning off the forcefield means that the lever can be interacted with just like any regular lever - no changes necessary to the event type.
The code above should give the following output:
Working Lever was touched!
Working Lever was pulled!
Working Lever was lever-pulled!
Electrified Lever was touched!
ZAP!
You hit the forcefield around the lever!
Forcefield Lever was touched!
Forcefield Lever was pulled!
Forcefield Lever was lever-pulled!
Forcefield Lever was forcefield-lever-pulled!
As a side note - things like "forcefield-lever-pulled" might seem clunky, but what they represent is the ability to code for specific actions to take place for specific object instances. For instance, a pressure plate might open the door in front of it, and not every single door on the map.
My next minor goal is to find a way to cleanly "ignore" certain event types: for instance, we might not want to do anything when a lever is touched, if the more specific event is a "lever-pull". My solution should still allow the user to say things like "touch lever", but should also allow the programmer of SpecificLeverPull events to declare that the parent Touch events should do nothing.