14.3.4. Removing a role instance
Roles form the connections between contexts. A role can be filled by another role (usually a role from another context) and a role can fill many other roles. These connections are bi-directional in the sense that a query can traverse them
-
both from a role to its filler, and
-
from a filler to the role(s) it fills.
Think of these connections as pointers in and out of the role instance. It is convenient to name these two types of pointers:
-
a role can have many fills pointers;
-
but it has only one filledBy pointer.
When a role is removed, we only detach the pointers towards the role instance. We need not remove the outward pointers; we’re going to throw the role away, anyway. So, for any role instance to be removed,
-
we remove the filledBy pointer from all roles that are filled by it, and
-
we remove the fills pointer from its filler.
A user is endowed with a set of perspectives that are qualified by role- and property-verbs, including verbs that affect roles:
-
Remove
-
Delete
-
RemoveFiller
-
RemovePropertyValue
A user can only remove roles she has a perspective on with verbs Remove or Delete. Notice that Remove and Delete effectively imply RemovePropertyValue and RemoveFiller.
14.3.4.1. State evaluation
Before a role is removed, it exits all its active states. The deepest nested active state(s) are exited first, meaning their on exit actions are executed first. The actual algorithm is formulated the other way round:
-
For each state:
-
exit active substates;
-
execute the on exit action.
-
And this starts with all root states of the role. All these actions are executed in the same stage! Subsequent automatic actions due to state changes caused by these on exit actions are all postponed to the next stage.
Furthermore, the automatic actions are execute before the pointers into the role are removed. This means that the statements are executed on the structure as it exists before removal. This is important, because it allows the modeller to modify remote parts of the web of roles and contexts from such an on exit action.
14.3.4.2. Synchronization
There may be peers in roles that have a perspective on the role instance that is removed. They should be informed. We compute these peers using the network prior to the removal of the resource! This should be obvious: we find peers by following outgoing links. When the resource is destroyed, there are no outgoing links left.