10.3. Contextualization
The functional languages Haskell and Purescript have a feature that is called type classes. They may be compared with interfaces as known in other languages. In Haskell/Purescript, a type class can have instances, where an instance is a type that must supply an implementation for the types (usually functions) that make up the type class. In some cases, the compiler is able to derive instances automatically.
Type classes allow us to decorate a type multiple times with ‘behaviour’ in terms of functions. It is in that respect superior to (singular) OO inheritance.
Perspectives allows contexts to have another context as an aspect, effectively giving the former to the latter as an extra, or super type. It also allows us to add the roles of other contexts, effectively allowing context composition. The same holds for roles: a role can have an aspect role, adding the aspect roles properties to it and ‘inheriting’ the aspect role’s restriction on its possible fillers.
Aspects are, in a way, to Perspectives what type classes are to Haskell and Purescript.
User roles have Perspectives. They, too, can be composed of Aspect (User) roles. What if the latter have Perspectives, too? In this text we explore the space of meanings we can give to such compositions. It turns out that Queries, Actions and Automatic Actions must be ‘contextualised’ when taken from an Aspect and incorporated into a decorated context.
Contextualising can be compared to supplying the implementation of a type class’s types in an instance. It turns out that the Perspectives compiler can derive all these ‘instances’ automatically – that is, it can carry out contextualisation automatically without requiring any action on the part of the modeller.