Subjects, Objects and Values

Subjects, objects and values (and not only the three) define a type system and mechanism of abstractions in Paml language.

General remarks for the type system

The idea is to define very strict language elements, with very concrete semantics and behaviors. It is similar to functional approach, where a function is such the element.

Since Paml is a modeling language, "symbolic abstractions" can be used. Symbolic means that semantics of a name in a model may not be defined in the model, but later via transformations. So model writer uses domain terms, and then transformations define what meanings the terms have and what output code should be produced.

Values

Values actually are data in wide sense. Values can be read and written. A value consists of items, which are values as well. Values (and value items) have a type, which may be any name (symbolic abstraction?).

An abstract sequence of values is a collection. A collection is not a list or array, or any low-level data structure.

For practical use, values define data relations in SQL manner, like one-to-many relation. This this a language feature, it allows placing all such information in explicit and single location. Transformations will produce actual DB scheme or low-level data structure like lists.

Values are not the same as value types in C# and similar GPL. A value in Paml is an abstraction with some structure to store data.

Values are neither objects nor subjects. To operate on values, only data access operations can be used.

Objects

Objects are abstractions to represent terms of the domain of a modeling system. An object has a state and a set of messages (like an interface or contract).

An object state is strictly a value. An object state is an abstraction; there are no properties, fields or something else in objects. The only way to manipulate an object is to send a message. This does not result to Java-style getter/setter methods: in Paml objects as abstractions such elements as properties are not required at all.

To operate on objects, only object access operations can be used. Actually for now, only one object access operation is defined: to send a message to object. Object state is not accessible directly via object access operations.

Objects are not the same as reference types in C# and similar GPL. An object is an abstraction to represent a term from a system domain or application one. Such important thing as creating an object is actually aspect, but not responsibility of an object.

For object messages and collaborators, a separated article will be provided.

Subjects

A subject is an object with special role in modeling, so all features of objects are completely relevant to subjects. Subjects are objects that represent high level of interaction in a modeling system.

Subjects can be actors that initiate or trigger some behavior cases or scenarios. Or subjects can be high level objects in architectural design.

So the idea is to distinguish subjects (high level interaction) and objects (represent some domain term or piece of functionality). Subjects are candidates to describe a "topology" of an application. Topology could be a map to distribute an application over some executing nodes like CPU cores or network computers.

The initial semantics of collaborators feature was designed only for subjects, but now seems collaborators are relevant for objects as well.

Code example

Below is an example of syntax for subjects, object and values.

The dotted rectangles specify the syntax elements where transformations can be applied. They are similar to "join points" in AOP terminology. IDE should provide rich capabilities for working with "join points" to display all relevant information: what transformations are applied to an element, what output code is produced from the element etc.