Perspectives Technical Documentation

3.1.4. More on states transitions; automatic effects

Life is full of repetitious tasks. Automation can take care of them and Perspectives is no exception. But when we make something happen automatically using Perspectives, it will always be delegated by some user role. Here we mean by ‘something happens’ that the information recorded in terms of contexts, roles and their properties, changes; in other words, that the state (of some context or role) changes.

So to make this very clear: state changes are always traceable to some (exactly one!) end user.

Let’s consider a birthday party. On entering the Root state of the Party (which happens as we create it), we’ll create a role PartyPig (to be filled later by a person). This is the model:

domain Parties
  case MyParties
    user Organizer
      perspective on Parties
        only CreateAndFill
    context Parties filledBy BirthDayParty
      on entry
        do for Organizer
          createRole PartyPig in binding >> context
  case BirthDayParty
    user PartyPig

The first thing to note is that all birthday parties (all instances of BirthDayParty) are embedded in the context MyParties. The context role Parties holds them. The user role Organiser can create a new one and fill it automatically with an empty embedded context (an instance of BirthDayParty) as well, due to the role verb CreateAndFill.

This is the only way we can create contexts. Thus, each context is always embedded through a context role in some other context. The role verb CreateAndFill governs this.

But this context is created empty and we always want to have an instance of the PartyPig role in it. This is where the on entry comes in. We then automatically create a role PartyPig, an automated task delegated by the Organizer user role.

You will notice the clause in binding >> context. It traces a path from the new Parties role instance (the current object) to the new embedded BirthDayParty context that it is filled with. This is where we create the new instance of the role PartyPig.

Notice that the current object as we’ve defined it above is actually available as the value of the variable origin in expressions.

We might have written this model like this:

domain Parties
  case MyParties
    user Organizer
      perspective on Parties
        only CreateAndFill
        on entry of object state
          do
            createRole PartyPig in binding >> context
    context Parties filledBy BirthDayParty
  case BirthDayParty
    user PartyPig

There is no difference in meaning; just in the way we express it.

By now you will have inferred that the line do for Organizer sets the current subject to Organiser. But why do we write on entry of object state and not just on entry, like we did in the first formulation?

This has to do with the notion of current state. We’ve seen that in the body of a state definition, that state is the current state. But what is the state outside of such scopes?

By construction, in the scope of a context definition, the current state is the Root state of that context. Similarly, in the scope of a role definition, the current state is the Root state of that role. Finally, we also have in state expressions that, unsurprisingly, set the current state.

So in our second formulation of the model, the current state in the lexical position at the start of the line on entry of object state is the Root state of the Organizer role. But we obviously do not want the automatic effect to take place on creating an instance of the Organizer role – it should happen when we create an instance of the Parties role! This is what on entry of object state does for us: it sets the current state that the on entry applies to, to the Root state of the current object. And this happens to be Parties (it is the first enclosing scope that sets the current object).

Looking back to the first formulation, we can understand why on entry works. The current state at this lexical position is given by the declaration context Parties – and thus is the Root state of Parties.

There are a lot of ways to set the current state. Summing up:

A state definition sets the current state for its body.

In all rules we list below, ‘setting the state’ holds for the lexical scope following the declaration or clause lines.

A context definition sets the current state to the Root state of that context.
A role definition sets the current state to the Root state of that role.
The in state X clause sets the current state to its substate X. When of and a state type (object, subject, context) is specified, the current state is set to the substate X of the current object, current subject or current context respectively.
The on entry and on exit clauses do by themselves not change the current state, but specify a state transition for the current state.
The on entry and on exit clauses can be augmented with three parts:
1. of object state, optionally extended with a state name. It sets the current state to the Root state (or the named state) of the current object;
2. of subject state, idem, for the current subject;
3. of context state, idem, for the current context.

These definitions and clauses give us full control of specifying the conditions under which something may happen automatically, in various ways.

In case you wonder why perspective on does not set the current state, see the paragraph Why perspective sets no state.

Some examples:

  on entry
  on entry of object state
  on entry of object state Published
  in state Published
  in object state Published
  in context state Published