InPlace Version v0.17.0 delivers no milestones in the project Practical Tools to Build the Context Web as supported by NLnet. Instead in introduces contextualising: the automatic adaptation of perspectives of aspect user roles in a new context.
Contextualising. 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.
InPlace Tutorial. We have written a self-paced instruction for InPlace. After completing this instruction, you will have performed the following actions:
This is a simplified version of model:TestAliases, a model used for testing the various facets of contextualisation:
domain TestAliases
use sys for model:System
use ta for model:TestAliases
case TestAliasesApp
indexed ta:App
aspect sys:RootContext
external
aspect sys:RootContext$External
user Manager = sys:Me
perspective on Transports
-- A choice of Flight and Car is offered when Manager wants to create a Transport,
-- because those two contexts use Transport as an Aspect.
defaults
perspective on Transports >> binding >> context >> Driver
defaults
context Transports (relational) filledBy Transport
on entry
do for Manager
-- With contextualisation of actions, a Pilot will be created
-- in a Plane (instead of a Driver).
bind sys:Me to Driver in binding >> context
case Transport
external
property Name (String)
user Driver filledBy sys:PerspectivesSystem$User
property VehicleName = context >> Vehicle >> Name
perspective on Vehicle
only (Create)
props (Name) verbs (SetPropertyValue)
perspective on Driver
props (VehicleName, FirstName, LastName) verbs (Consult)
perspective on extern
props (Name) verbs (SetPropertyValue)
thing Vehicle
property Name (String)
case Flight
aspect ta:Transport
user Pilot
aspect ta:Transport$Driver
thing Plane
aspect ta:Transport$Vehicle
case Car
aspect ta:Transport
user Chauffeur
aspect ta:Transport$Driver
-- Because we have added the aspect role Vehicle as such, we expect Chauffeur to have
-- a perspective on it.
-- Incidentally, since the external role of Transport is added automatically to
-- the external role of Car, we expect Chauffeur to have a perspective on
-- that external role as well.
-- Additionally, notice that the tab in the generated screen should be called "Vehicle" - as
-- the model provides no alternative.
aspect thing ta:Transport$Vehicle
The more interesting points from the Git commit log (except for the commits to the major changes):