release
Gives back exactly the space this allocation covers, and complains if it is not current.
The form to prefer. releaseZones taking a holder is keyed on object identity, and a holder is minted during the run -- so releasing the wrong instance of a crew, or a crew whose space has already gone back, is an easy slip that does nothing at all and says nothing about it. The zone stays closed for the rest of the replication and the model quietly stops being the one that was written.
An allocation cannot be got wrong in that way. It is handed to ZoneHoldActionIfc.holdBegan at the moment the hold began, it names one hold rather than one holder, and releasing it twice raises instead of passing silently.
override fun holdBegan(allocation: ZoneAllocation) {
mine = allocation // hold on to it
}
fun cleanupFinished() {
space.releaseZones(mine) // and give back exactly that
}Parameters
the grant to give back, as handed to ZoneHoldActionIfc.holdBegan
Throws
if it has already been released, or is not the holder's current grant on this guide path
Gives back whatever a holder holds, or gives up what it asked for and never got.
Harmless when it holds and wants nothing, which is what lets a process release unconditionally rather than asking first -- and that forgiveness is exactly why the releaseZones that takes a ZoneAllocation is the better form for a model to use. A holder is made during the run, so naming the wrong one here is silent and leaves space closed for good; naming the wrong allocation raises.
A request given up while it was still draining tells nobody, and that is the contract on ZoneHoldActionIfc rather than an omission: abandonment is always the caller's own act, so there is nothing the caller could learn from being told about it.