ComponentModel

From Lorien Documentation
Jump to: navigation, search

Contents

Reference sheet

Below is a quick reference sheet describing every possible aspect of a Lorien component and its language constructs; not all components will necessarily use all features mentioned. Click on the image for a full-size version intended for printing on A3 paper.

ReferenceSheet.png


The compilation process

Lorien's component model uses a very minimal extension of the C programming language. The vast majority of source code is passed directly to a C compiler completely unmodified. Before a component's source code is passed to a C compiler however, Lorien's component compiler treats the component-oriented syntax to convert it to a plain C representation. Here we discuss in detail Lorien's component syntax and how it is treated by both Lorien's component compiler and the C compiler.

Component-oriented syntax

Declarations

component provides{...}

Lorien's component compiler reads the types of the interfaces declared here, and checks them against implementations of their functions in this component. The types are also used to search for, and generate #include statements for, the header files in which the interfaces are defined. Appropriate code is generated inside the component's constructor to register these declared interfaces with the runtime, and to link this component's function implementations to those registered interfaces.

component requires{...}

Lorien's component compiler reads the names of the interfaces declared here, and their types, and uses the names later to locate and convert each reference to a required interface to the appropriate cross-component call mechanic. The types are also used to search for, and generate #include statements for, the header files in which the interfaces are defined.

component state{...}

The members of the component state declaration are passed directly to the C compiler; Lorien's component compiler just reads the names of each member of the state declaration and translates the container to a struct. The names are used later to locate and convert each reference to a state field to the appropriate component instance state lookup.

Special symbols

this

The keyword "this" is simply translated to a component instance reference. In plain C form it is a pointer of type Component.

hashcode()

This is a special pseudofunction of the same kind as sizeof(). Lorien's component compiler replaces it at compile-time by the string literal containing the corresponding hash code of the interface type provided as a parameter. In practice this function is rarely used (typically by components supporting callback registrations).

Function modifiers

IInterface:function

This indicates that this function is an implementation of one of the functions in the interface IInterface. function must therefore match one of the function names in IInterface, and the remainder of the function prototype must also match (i.e. parameters, return value).

pure

This function modifier indicates that this function should not be treated in any way by Lorien's component compiler. The "pure" keyword is simply removed by Lorien's component compiler and the function is passed completely unmodified to the C compiler. No state accesses or cross-component calls can be made from within such a function. You also cannot call any non-pure functions from pure functions.


Interface variants

Components can declare multiple provided and required interfaces of the same type using "variants". Multiple non-varianted provided or required interfaces of the same kind are not permitted because Lorien cannot then distinguish between them.

The following for example:

component provides{
   ILed;
   ILed;
   }

Is not legal; nor is:

component requires{
   IMXRadio *primaryRadio;
   IMXRadio *secondaryRadio;
   }

We therefore use the notation InterfaceType:Variant to support multiple same-type interfaces in our provides or requires declarations.

For provided interfaces this looks like:

component provides{
   ILed:Red;
   ILed:Blue;
   }

And the implementations of these functions look like:

static int ILed:Blue:on()
   {
   ...
   }

And for required interfaces this looks like:

component requires{
   IMXRadio:Primary *primaryRadio;
   IMXRadio:Secondary *secondaryRadio;
   }

Any varianted required interface can be connected to any type-compatible provided interface regardless of their variant qualifiers matching up.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox